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: Pedro Lopez-Cabanillas
Subject: Re: CMake (was Re: [fluid-dev] Voice renderer, and fluid_voice_t)
Date: Sun, 20 Jun 2010 23:57:17 +0200
User-agent: KMail/1.9.6 (enterprise 20070904.708012)

On Sunday, June 20, 2010, David Henningsson wrote:
> 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.

I can do the required maintenance for the CMake build system, but the basic 
tasks, for instance adding new sources and headers to the build system, is a 
very trivial task, and you should not be afraid to try. Even without any 
guidance I'm sure you will be able to accomplish it. And if not, you can 
request my help at your discretion.

> 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? 

CMake is available in Linux (packaged by all major distros) and all Unix 
variants, Windows and Mac OSX. There is a recent port to OS2, but the 
operating systems where it is not supported are listed here:
http://www.cmake.org/Wiki/CMake:OpenTasks

> 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 :-)

I offer you my assistance, by e-mail or jabber.

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


Regards,
Pedro



reply via email to

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