[Top][All Lists]

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

Re: [fluid-dev] [ANNOUNCE] FluidSynth 1.1.4 released!

From: Orcan Ogetbil
Subject: Re: [fluid-dev] [ANNOUNCE] FluidSynth 1.1.4 released!
Date: Thu, 4 Aug 2011 12:19:25 -0400

On Thu, Aug 4, 2011 at 11:27 AM, Pedro Lopez-Cabanillas wrote:
> On Thursday 04 August 2011, Orcan Ogetbil wrote:
>> On Thu, Aug 4, 2011 at 3:54 AM, David Henningsson wrote:
>> > In short, version 1.1.4 of FluidSynth brings us:
>> >
>> >  * Several improvements and fixes to the CMake build system,
>> >   especially for Mac OS X
>> >  * Several bug fixes to the engine, notably quite a few which could
>> >   cause FluidSynth to sound bad in some cases.
>> >  * API additions, that make it possible to
>> >   - load MIDI files from memory
>> >   - to inspect/modify MIDI events as they are being played from a
>> >     MIDI file
>> >   - to change channels between melodic and drum mode
>> >   - and to silence all notes in one command.
>> >  * Improvements to the CoreAudio driver
>> >
>> > A more detailed list of changes is available at
>> > https://sourceforge.net/apps/trac/fluidsynth/wiki/ChangeLog1_1_4
>> >
>> > Looking back at the changes, I'm feeling a little proud today. One of the
>> > reasons for feeling proud, is that we have more than one new contributor:
>> > people who have taken the step to actually work with the code, improve it,
>> > and create non-trivial patches with new functionality in it. That is a good
>> > foundation for the future and I hope all contributors feel welcomed and
>> > properly attributed.
>> >
>> > Also, the improvements/fixes to the build system is worth a special note
>> > (thanks Pedro!), I was surprised to see so many of them! And finally, we've
>> > managed to close several long standing bugs, which makes me feel that this
>> > release will be stable and enjoyable for a lot of people, with less
>> > annoyances than ever. (Thanks to the jOrgan folks for the test run!)
>> >
>> > Now, enjoy the release, and last but not least - make sure you make some
>> > really great music with it! :-)
>> >
>> > On behalf of the FluidSynth developer team,
>> >  David Henningsson
>> >
>> Hi all, thanks for releasing 1.1.4. Sorry I did not have time to test
>> the prerelease tarball you made the other day. I was planning to do
>> this today.
>> Anyhow, I saw in the CMakeLists.txt, a couple lines such as
>> Unfortunately this is wrong. The variable ${LIB_INSTALL_DIR} is
>> already expected to have the lib suffix in it, i.e. it is set to
>> /usr/lib64 on multilib 64bit systems. This is the cmake standard we
>> have with hundreds of packages in Fedora.
> This may be the standard in Fedora, but it is not a CMake standard at all. 
> You can ask in the CMake mailing list, or search for similar questions in the 
> archives, for instance:
> http://www.cmake.org/pipermail/cmake/2011-March/043180.html
> I've adopted the variable name "LIB_INSTALL_DIR" because i'm used to it in my 
> KDE projects, but it is not a standard outside KDE. The FluidSynth's 
> LIB_INSTALL_DIR is a constant defined in cmake_admin/DefaultDirs.cmake, with 
> the value "lib". The other variable LIB_SUFFIX is initialized in the main 
> CMakeLists.txt with the value "64" or empty. You can override the 
> initialization value of these variables in the command line, if you want:
> $ cmake .. -DLIB_SUFFIX=""
> This can be easily added to the RPM spec file too. I find this method much 
> more comfortable than applying patches.

Hi Pedro,

Sure the behavior can be overridden that way. However, when building
RPMs, there are cmake macros we use that pass all the standard flags
to all packages that use cmake. I am sure other RPM based
distributions, or even DEB ones use some sort of standardization in
cmake flags too.

I really do believe that what I claimed is a  (maybe unwritten) cmake
standard, since we do not have to do such overrides you suggested for
any other package (we have a lot of them). I also adopt this
convention in my projects where I am the upstream. Of course,
fluidsynth can be a special case, but does it really have to be?

Thank you for your time,


reply via email to

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