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 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.
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 behaviour. (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 builders.
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 ?
no
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...
mfg.a.dsr IOhannes