Any reason for the EFL/Core/Studio split?


#1

Hi,

I have just downloaded the Synfig Git repository and noticed that the code is split among three codebases - EFL, synfig-core and synfig-studio - each with its own build system. As these three always seem to be distributed together, there doesn’t seem to be a good reason for this separation, so why is there? Is it a historical artifact?

Maybe it would be better to combine all three code bases in a single build root, with only one central autoconf file, like so:

synfig/
    etl/
        Makefile.am
        ....
    core/
        Makefile.am
        ....
    studio/
        Makefile.am
        ....
    configure.ac
    Makefile.am
    ...

This would ensure that all three are always in sync and reduces the need to define dependencies. With this setup, ETL could even be compiled into the synfig binaries statically, which would further simplify the setup and avoid the target system to be “polluted” with a shared library that is not used by any other program anyway.

What do you think?


#2

The main reason of have three separated modules is that the synfig core holds the command line interface and it can be an independent application. It defines also the libraries used in synfig-studio.
The ETL libraries could be combined to synfig-core but we haven’t got time to do it.

So synfig-core is provides one independent application (the CLI) but is directly used by synfig-studio.

Also, synfig studio cannot be compiled without synfig libraries installed and synfig CLI installed too. The icons are rendered at build install time from the source files.

-G


#3

I understand that synfig-core contains the command-line interface; what I meant is that it is never distributed separately, and there really is no reason for doing so. This is why I am saying that a single autoconf configuration would be much easier to manage, and much easier to build for people who want to test out git master. (For building only single modules, you could still change into the individual directories and do “make” there.)

Maybe I’ll be able to help someday; I’m actually studying the code right now out of interest. It seems that, in fact, quite some ETL base functionality could be removed that is actually available in the C++ standard library now. For instance, since quite some time most compilers have shared_ptr for reference counting. For the rest, there is Boost, which would take the burden to implement such low-level facilities from your shoulders. :slight_smile:

If synfig-core and synfig-studio were part of the same build, the latter could just use the built versions of the former in the source directory. This change would probably be easy enough to make.

I’m not trying to talk you guys into anything, I just want to explain why I think that change would be nicer for everyone. :slight_smile: (I could prototype it if you want!)


#4

It could be great if you want to work on unify configuration and make a more solid package for developers. I’m not so much expert on autotools so I don’t dare to work on it without risk of break everything.
I just know C++ and has lately started to understand the synfig code.
Any help is welcome. We only want that the help were in a middle long term as minimum to don’t start a huge change and leave it uncompleted.
Please use the wiki and or the forum for further proposals. You’re welcome!
-G