[GEM-dev] the myths of configure
geiger at xdv.org
Wed Jun 1 11:22:06 CEST 2005
On Tue, 31 May 2005, IOhannes m zmoelnig wrote:
> wow, for 10 seconds my MUA showed very weird asteriskes and symbols.
> it has serious problems with guessing the correct encoding of your
> emails.... (but it was fun to look at)
> it seems to be fine, but it will only work if a package comes with an
> appropriate .pc-file. (.pc like "pkgconfig")
> some packages do (on debian at least) some dont (like ffmpeg); but it
> seems that far more packages come with a .pc-file than with a "*-config"
> pkgconfig is also cross-platform, so in theory it should work well on
> osX; the only package that would be of interest here is probably ftgl:
> is there an ftgl.pc file somewhere ?; it seems like the one in the
> debian-distro is provided by the package-maintainer.
Yes, the FTGL build system is not very good in general. I only put
the PKG_CHECK_MODULES for packages that actually support pkgconfig,
and thats how it should be IMO.
> >>- are options generally a bad style ("--without-ftgl") or are they
> >>missing just because you didn't care ?
> >>should we re-do them ? has the way they have been used been dirty (i am
> >>not much of a autoconf-hacker) ??
> > I think that the system should give reasonable default values whenever
> > possible. That is, if there is FTGL installed on the system it should use
> > FTGL. But its not bad style, it changes from case to case.
> > So if there is a real need for being able to adapt which libraries are
> > used, then a --enable --disable makes sense.
> as a developer i prefer the option to explicitly disable/enable things
> at my will (so i can more easily reproduce the behaviour on machines
> that lack a certain library)
> i have no idea how you do as a package-maintainer: i thought being able
> to explicitely specify how the package should be build should ease your
No, its easier if the author of the software has taken the decision for
me. Decisions need additional knowledge, and the knowledge I have as
package maintainer can never match the knowledge of the author of the
> e.g. you have commented out the support of libdv in the configure.in
> script, in order to disable it.
> wouldn't it be far simpler to give a command line flag to configure that
> it should not use libdv because gem-0.90.0 and libdv4 don't like each
> other ?
I can't remember what was wrong, but a commandline flag is not the
solution to the problem.
> i don't know the new debian build system, but i remember well that the
> old build scripts were usually filled with configure-options.
Normally they are standard configure options, like the path were to
install things. Another advantage is to have options for non-free
features (like ffmpeg has, for example).
> and of course it should be possible to package Gem without the need to
> patch the source-code.
Yes it should. The current build system is just too messy and slow, thats
why I changed it. I had written that in 98 or so, so I thought it is time
for an update.
> but i was rather talking about the mess in my (local) source-tree, which
> i don't want to tidy up...
> and it is not only me: jamie complained that he did a backup-copy of
> (say) "cube.cpp" which was automatically named (by finder) "copy of
> i think, not using "finder" for doing backup copies is not an option (at
> least, using configure should not keep anyone from using their favourite
> so the options are: - delete the backup-copy entirely (why did i do it
> in the first place?)
> - compile with the backup-copy: this could break compilation due to the
> bad filename;
> what is worse is, that if compilation succeeds and we have a "copy of
> cube.o" besides the "cube.o"; which might seriously break
> auto-registering of the Gem-objects, and be very hard to find.
I think that the mess in your source tree is a bad reason for having
and overcomplicated build process.
> > I don't have any problem if you don't, it was just that it was lying
> > around already.
> well, i have a initial running version, i am not sure whether to check
> it in right now (jamie, does Gem now compile fine on tiger with the
> autoconf/make ? if so, could you commit any changes....)
I don't know if you should accept it. The point of accepting it is that
you understand which problems it tries to solve and improve that.
Otherwise it will only be a source of frustration.
> but the real question i had was:
> how do i check the existance of a special function in a library ?
> if i do in configure.in:
> AC_CHECK_LIB(GL, dududa)
> then running configure just gives me:
> checking for dududa in -lGL... yes
> which is not what i want (i'm pretty sure, that "dududa" is not defined
> in libGL)
I have never seen such a behaviour from autoconf.
--- quote ---
Macro: AC_CHECK_LIB (LIBRARY, FUNCTION, [ACTION-IF-FOUND],
Depending on the current language(*note Language Choice::), try to
ensure that the C, C++, or Fortran function FUNCTION is available
by checking whether a test program can be linked with the library
LIBRARY to get the function. LIBRARY is the base name of the
library; e.g., to check for `-lmp', use `mp' as the LIBRARY
--- end quote ---
a serious bug in autoconf ?
> so how does one do such function checks in a generic way ?
More information about the GEM-dev