From: Chris C. <ca...@al...> - 2010-02-19 10:44:07
|
On Fri, Feb 19, 2010 at 6:54 AM, D. Michael McIntyre <mic...@ro...> wrote: > On Thursday 18 February 2010, Orcan Ogetbil wrote: >> 3) Fedora's rules tell us we need to pass specific flags to the >> compiler. However the environment variable CXXFLAGS is being overriden >> by the configure script. The only way I could hack this around was to >> pass a sed 's|@CXXFLAGS@|%optflags|' to Makefile.in. Can we make this >> a bit easier? > > Yes, although I find this solution questionable. I'm no build system guy, and > not really qualified to have an opinion on this, so I'm putting a hold on > resolving this issue until Chris Cannam weighs in. > > Chris, if you please? Happy to do something to help out here, but I want to be clearer on what's needed. The configure sets CXXFLAGS to contain both defines that are meaningful to our code (e.g. NDEBUG, BUILD_RELEASE, NO_TIMING in release mode) and compiler flags (-O2 et al). This is not good form already, the two should be substituted separately. Am I right in thinking you'd like to override _just_ the compiler flags and to override them at configure time rather than make time (with configure baking your overridden flags into the Makefile for you)? So my first thought is to: * replace CXXFLAGS in configure.ac with two substitutions, say CXXFLAGS for compiler flags and DEFINES for defines * if CXXFLAGS is already set when configure is run, accept its contents (printing a note) and override the internal settings with them Would that work for you? >> 4) Fedora does not allow indirect linking with libraries anymore. If >> an application or a library uses symbols from another library, it has >> to link to it. Otherwise the compilation fails. I needed to pass the >> flags "-lz -lX11 -ldl" to the linker in order to make rosegarden >> compile on Fedora. It would be good to have this upstreamed as other >> distros may also follow Fedora in this regard. > > I tested to make sure this change had no apparent impact on Ubuntu, and it > didn't. I have no objection to upstreaming this for your convenience. Nor me, this is quite good form -- _if_ the libraries in question are universally required, at least on Linux. >> 5) This one may be very Fedora specific: The font .pfa files are >> compiled into the final binary. This is a big NO in Fedora. I had to >> patch them out and install them in /usr/share/fonts/rosegarden/. I am >> attaching the patch. You should be able to do this without modifying the source code by installing the fonts into /usr/share/rosegarden/fonts/ instead of /usr/share/fonts/rosegarden/. Anything in the resource file can be unbundled into /usr/share/rosegarden/<resourcepath> and will be picked up from there if found. (At least, that's the idea -- it isn't very thoroughly tested, but if it didn't work we'd fix it.) I would not be keen to accept a patch for /usr/share/fonts/rosegarden, it's ontologically misleading (they are not our fonts, they're just installed specifically for our package). > This has been something of a contentious issue, and it makes me remember the > bad old days when JACK was impossible to get into distros because Paul Davis > steadfastly insisted on static linking everything, and would rant about it if > you asked him to, or even if you didn't. That was Ardour, not JACK. He compiled in all its C++ library dependencies to avoid errors resulting from C++ binary incompatibility. Probably still does, in fact. > My take on this is that bundling everything into the binary is clean and easy > to maintain, and it doesn't bother me a bit. Being able to run 15 different > ./rosegarden without ever installing anything is extremely useful for > development, and extremely convenient for users who inevitably wind up > compiling some SVN snapshot in between releases, and will want to run it > alongside their stable release backup version (which is one of the exciting > key benefits of the new Rosegarden). > > How can we reconcile all of this so everyone wins? I think we leave bundling as the default -- and if we ever distribute a binary, which we could have a crack at just for grins, we make it fully bundled -- but allow distrae (thanks) to unbundle when installing. I would very much prefer the source code to be the same in both cases though. >> 6) The DSSI and LADSPA plugin paths are wrong on 64 bit systems. I am >> attaching a patch to correct the issue. > > Wrong on 64-bit systems on certain distros. Yup, we wouldn't accept this patch as it stands. There's a strong case that the proper place to find libraries that are compatible with binaries in /usr/bin is /usr/lib. I'd be happy to see a clever way to find the right path, but if we're going to have platform-specific hardcoded paths, we might as well have the simplest possible ones as we have now. Otherwise patch it for the distro, or make sure your path environment variables are set correctly. Chris |