fluid-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CMake (was Re: [fluid-dev] Voice renderer, and fluid_voice_t)


From: David Henningsson
Subject: Re: CMake (was Re: [fluid-dev] Voice renderer, and fluid_voice_t)
Date: Sun, 20 Jun 2010 20:57:08 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4

On 2010-06-20 17:32, Pedro Lopez-Cabanillas wrote:
> On Sunday, June 20, 2010, David Henningsson wrote:
>> To get to know the voice code better, I've done some refactoring which
>> is already in trunk. And as the number of source files increase, so does
>> the need for subdirectories. Any objections to me organizing the source
>> files in subdirectories?
> 
> There is an alternative CMake build system in trunk, added in SVN revision 
> #287 (3 months ago). See also ticket #38,
> http://sourceforge.net/apps/trac/fluidsynth/ticket/38
> 
> I've announced it on this list, and asked for comments and testing. Nobody 
> answered, reported problems or success. 
> 
> Today, it is not possible to compile FluidSynth using this new build system, 
> because there are source files that weren't included in src/CMakeLists.txt, a 
> file with a simple syntax not very different from src/Makefile.am that has 
> been updated.
> 
> I think that there are advantages in using CMake (see README.cmake) but if 
> nobody else supports it except me, it would be a waste to keep and maintain 
> it. 
> 
> I don't have any objection about organizing the source files in 
> subdirectories, but that would require keeping in sync both build systems. If 
> you are not interested, please feel free to remove the files added in 
> revision #287 and close the ticket #38.

Right, we need to have a build system discussion, to determine which of
these three ways to take (in no particular order) :

1) Maintain autotools and throw CMake out
2) Maintain CMake and throw autotools out
3) Maintain both build systems

I'm not a big autotools fan, but I know the basics. I know almost
nothing about CMake, so I haven't done much about it, hoping that
someone (likely yourself) would keep it up to date.

Maintaining both build systems seems to me like more work than gain, and
we're likely break one in the long run, as long as both are not actively
used by people. That's at least my fear.

But is it an option to throw autotools out in the long run? Are there
platforms we currently support which will not work with CMake? Other
problems we should be aware of? I will gladly to consider alternatives
to autotools, and I'm definitely willing to learn, but I could use some
enlightenment :-)

It would also be good to have Elimar's opinion (if any) on this.

// David



reply via email to

[Prev in Thread] Current Thread [Next in Thread]