Can’t start making a cmake script if I don’t know how synfig builds.
Hi!
Can you be more precise on your question?
-G
What essentially saying that in order for me to create the cmake script I need detail by detail information on how the synfig is compiled. Documentation on the building process in other words.
This is all we have:
wiki.synfig.org/wiki/Developer_Documentation
autotools help and cmake documentation are your friends.
-G
That’s didn’t help one bit, you just indirectly told me to “figure it out” or “do it yourself”. I need information. No information, no cmake. That’s why I’m asking.
For a generic open question I don’t have specific answer. Also I have difficulties to understand how it builds (the configure > make process is difficult to understand for the autotools and the only information available are the autotools help and the corresponding configure.ac files and the makefile.am files).
If I would have understood “how does it build” I would have migrated to cmake long time ago.
-G
Do you know anything about autotools?
I can explain the little bits that I know from fiddling with the build scripts, but I’m not sure anyone here understands the entire process. (The most confusing part has to do with libtool, how synfig-core code is compiled into both an application and a library, and how that library is linked with synfig-studio. I know roughly what’s going on, but am clueless as to the details).
Are you telling me that nether of you know how synfig builds? That’s (to be briefly put it) Terrible. How the heck is synfig going to migrate to a better build setup if we don’t have a single clue on it?
You’ve hit the truth here: if any of us actually understood autotools in its entirety, we either wouldn’t have reason to migrate to cmake, or we would have done so long ago. I only learned enough about the build system to allow for new C++ files and libraries.
The folders synfig-core/ and synfig-studio/ have a configuration file called configure.ac. I’ll use the synfig-core file as an example. At the top of the file there are variables specifying the name of the program and its versions.
Next is an arguments section, which interprets command line arguments to the ./configure script. It typically adds something to CFLAGS or CXXFLAGS, which hold arguments that will be passed to the compiler. Or it defines a preprocessor variable for all files that are compiled. (It does so by creating a file called config.h, which is included by default when anything is compiled). There are also checks whether a particular library or header file exists before enabling certain functionality.
Later on there is a definitions group, starting with HASH_MAP_CLASS. This is really a hack: the old C++ standard doesn’t support a built-in hash map, but various extensions do. There are several namespoces that might have a hashmap, such as “std:tr1” (defined by a draft extension to C++) and a compiler-specific namespace. C++11 should have added these features to the standard library.
Then there are checks that certain functions, like fork, kill, and pipe, exist. They are built-in on most Unix systems, but not on Windows.
Lastly it concatenates all the C/C++ compiler flags for different libraries, includes config files from subdirectories, and prints configuration results.
The other major files to care about are the Makefile.am files in each directory, which list all of the C++ files and headers that need to be compiled, and the application they correspond to.
Almost everything else (e.g. Makefile.in, Makefile, and the actual executables) is autogenerated from configure.ac and the *.am files by following the build instructions. There’s a bit more going on with doxygen documentation, installation, and packaging, but it’s semi-automatic and not necessary in order to build and run the program.
Adding new files and libraries to the existing build scripts is pretty straight-forward. Porting to a different build system, on the other hand, requires understanding how ETL, synfig-core, and synfig-studio are all linked together. That part is done automagically by the autotools scripts, so coming up with a cmake equivalent will take some research.
That’s beause autotools is complicated - it isn’t any fault of Synfig’s developers.
If you read the above history of KDE, you’ll find that when they migrated to cmake only ten people out of several hundred knew how the whole KDE autotools build system worked well enough to fix issues with it and that was a project far larger than Synfig which had commercial backing.
I’m certain most users here would much rather have the developers concentrating on the software rather than the build system.
You know we could start gathering information by looking at the generated make files. Can anyone create a wiki page on this, so we can put the gather information there?
Anyone with a wiki account can do that… you for example.
-G