[GEM-dev] the myths of configure

[=?X-UNKNOWN?Q?g=FCnter_geiger?=]

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)

Sorry :)

> 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"
> helperscript.
>
> 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
> task.

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

> 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
> cube.cpp";
> 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
> file-browser)
> 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],
          [ACTION-IF-NOT-FOUND], [OTHER-LIBRARIES])
     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
     argument.
--- end quote ---

a serious bug in autoconf ?

Guenter


>
>
> so how does one do such function checks in a generic way ?
>
>
> mfg.a.dr
> IOhannes
>