[GEM-dev] the myths of configure

IOhannes m zmoelnig zmoelnig at iem.at
Wed Jun 1 11:54:30 CEST 2005

günter geiger wrote:
> On Tue, 31 May 2005, IOhannes m zmoelnig wrote:

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

hmm. but debian provides an ftgl.pc, so this package supports pkgconfig.
but when we decide to use PKG_CHECK_MODULES, then all pkgconfig must be 
supported by platforms for a specific package.

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

yes i understand that.
my idea was always, that autoconf should be able to figure out what is 
available on the current system and build accordingly.
command line options should be _options_ (like in "optional") and not 
needed normally. but they should be there in order to enforce a special 
(e.g. i am thinking of a "--without-GL" to disable the build of the 
openGL-wrapping objects for people who want a small binary and don't 
care for the openGL-wrapper at all)

>>e.g. you have commented out the support of libdv in the configure.in
> I can't remember what was wrong, but a commandline flag is not the
> solution to the problem.

true. (but sometimes easiest...)

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

what does this mean exactly ? can you disable non-free code in the 
ffmpeg-sources with a configure option ?

just for my interest:
is the non-free section in Debian based on the source-code or the 
binaries.  ?
or: if i include non-free sources in my code but disable them (comments, 
ifdefs), is the code considered to be free then ?

> I think that the mess in your source tree is a bad reason for having
> and overcomplicated build process.

well somehow yes; but i think the build process is for those who want to 
compile a package. and developers probably belong to the most important 

>>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.
> a serious bug in autoconf ?


after some more investigation it seems to be a good reason for switching 
to a cleaner autonconf-script.
i just tried "AC_CHECK_LIB(GL, dududa)" within another configure.in and 
it works as expected...


More information about the GEM-dev mailing list