[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: Pedro Lopez-Cabanillas
Subject: Re: [fluid-dev] [ANNOUNCE] FluidSynth 1.1.4 released!
Date: Fri, 5 Aug 2011 17:15:05 +0200
User-agent: KMail/1.13.5 (Linux/; KDE/4.4.4; i686; ; )


I am very quiet, and have been answering this thread in a polite and friendly tone, even if I have all the right to feel angry after the false claim that you started with this sentence:

On Thursday 04 August 2011, Orcan Ogetbil wrote:

> 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 claim is false because the variable LIB_INSTALL_DIR is not defined by CMake at all. Anyway I've been trying to offer an easy solution to the problem you reported. But instead of admitting that you are wrong, and finding a constructive result from the discussion, you are insisting again:

On Friday 05 August 2011, Orcan Ogetbil wrote:

> On Thu, Aug 4, 2011 at 1:38 PM, Pedro Lopez-Cabanillas wrote:

> > On Thursday 04 August 2011, Orcan Ogetbil wrote:

> >> On Thu, Aug 4, 2011 at 11:27 AM, Pedro Lopez-Cabanillas wrote:

> >> > $ 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.

> >

> > Here are the options currently used in Debian to build the FluidSynth package:

> >

> > http://anonscm.debian.org/gitweb/?p=pkg-multimedia/fluidsynth.git;a=blob;f=debian/rules

> >

> > ( they set LIB_SUFFIX='' )

> >

> >> I really do believe that what I claimed is a  (maybe unwritten) cmake

> >> standard,

> >

> > Google is your friend. Show me evidences.

> >


> Sure:

> http://pkgs.fedoraproject.org/gitweb/?p=libechonest.git;a=blob_plain;f=libechonest.spec;hb=HEAD

> http://pkgs.fedoraproject.org/gitweb/?p=kdemultimedia.git;a=blob_plain;f=kdemultimedia.spec;hb=HEAD

> http://pkgs.fedoraproject.org/gitweb/?p=muse.git;a=blob_plain;f=muse.spec;hb=HEAD

> http://pkgs.fedoraproject.org/gitweb/?p=kmplayer.git;a=blob_plain;f=kmplayer.spec;hb=HEAD

> http://pkgs.fedoraproject.org/gitweb/?p=mscore.git;a=blob_plain;f=mscore.spec;hb=HEAD

> http://pkgs.fedoraproject.org/gitweb/?p=qsynth.git;a=blob_plain;f=qsynth.spec;hb=HEAD

> http://cvs.rpmfusion.org/viewvc/rpms/traverso/devel/traverso.spec?revision=1.5&root=free&view=markup

Your links point to several RPM specs, mostly from Fedora itself, that don't offer any demonstration that LIB_INSTALL_DIR is a CMake standard variable with the defined semantics of having the lib suffix in it. You can't disguise your intentions calling it an "unwritten standard". I don't buy such thing, let alone that we are discussing here about computing science, were all the standards should be publicly documented to deserve that title.

If you don't want step down your false claim, I'm not going to continue the discussion.



reply via email to

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