Need Automake Help

[Quasar]

I need help integrating zlib into EE. For Windows this is not a problem, but for Linux I need the library integrated into the existing automake system and I have very little idea of how to do it. The setup needs to look like this:

trunk/
trunk/zlib
trunk/source

I know that I need to add zlib to SUBDIRS in the trunk/Makefile.am file, but how do I then link the resulting static library to the executable built by the Makefile.am under trunk/source?

Joe quit precisely because I asked him to add the snes_spc library to the build system, which is in the exact same situation as this. The difference is, SPC support is a non-essential gimmick, but zlib is going to be a required dependency for at LEAST three features - ZDoom node support, the new planned zip-based savegame format, and PNG screenshots (libpng will require similar work). I need this to work before EE development can move on.

[Gez]

Maybe use CMake to generate these makefiles? From what I heard, it's a lot simpler to use than autoconf.

[RjY]

Generally on linux you wouldn't build an embedded copy of the zlib source yourself as part of your build process. Instead you'd use the one installed on the system. You'd write a bit of autoconf blurb in your configure.ac to detect the presence of the headers. If not found you either stop the build and complain, or disable the features that need the library to work.

(There are good reasons to use the system libraries instead of embedded copies in your source distribution; if a security bug is discovered in the embedded library, users just have one library to update instead of many applications.)

Anyway, appropriate code to do this in your configure.ac (aka configure.in) is something like

AC_CHECK_LIB(z, zlibVersion, [], AC_MSG_ERROR([please install zlib])

Disclaimer: I haven't tested this.

Edit: it's zlibVersion, not zLibVersion. Lower case l. Oops.

[Quasar]

RjY said:

Generally on linux you wouldn't build an embedded copy of the zlib source yourself as part of your build process. Instead you'd use the one installed on the system. You'd write a bit of autoconf blurb in your configure.ac to detect the presence of the headers. If not found you either stop the build and complain, or disable the features that need the library to work.

(There are good reasons to use the system libraries instead of embedded copies in your source distribution; if a security bug is discovered in the embedded library, users just have one library to update instead of many applications.)

Anyway, appropriate code to do this in your configure.ac (aka configure.in) is something like

AC_CHECK_LIB(z, zlibVersion, [], AC_MSG_ERROR([please install zlib])

Disclaimer: I haven't tested this.

Edit: it's zlibVersion, not zLibVersion. Lower case l. Oops.

Thing is I must have the source in the repo in order to use it on Windows. It seems kind of weird to be using one version for Windows and a potentially different one on Linux. Also consider that zlib has been stable for about 5 years now.

Also, how does this solve the problem of linking against it?

[Gez]

This might help. Maybe.
http://mancubus.net/svn/zdoom?view=rev&revision=1604

[andrewj]

Quasar said:

Also, how does this solve the problem of linking against it?

You just add -lz to the link step and the compiler will find the library in the system. Of course you need the development version of the library installed, e.g. apt-get install zlib1g-dev

Personally I don't touch the autoconf/automake stuff with a barge pole. It is way way too complicated to use, and I've noticed many configure scripts don't actually work on different systems (like they are supposed to) because most people can't understand how to make them properly.

[RjY]

If it finds the library, the default action of the AC_CHECK_LIB macro will add the appropriate flags to the command used to link the final executable.

You might also like to do

AC_CHECK_HEADER(zlib.h, [], AC_MSG_ERROR([please install zlib development headers]))

to make sure the headers to build against are there as well. Or you can get really complicated! (I wouldn't bother)

Andrewj: I'm not disagreeing with you - there are actual bugs in PrBoom's tracker about the configure stuff failing to detect things on user's systems that the user swears blind are there - but what do you suggest as an alternative?

[andrewj]

RjY: I wish there was a decent alternative, but the ones I've tried haven't been much better.

The main alternative I have used is SCons, which we used for EDGE (and EDGE has a lot of dependencies). While it seemed quite good at first, but when you want to do something that doesn't quite fit their model, then it falls over. For example, for Linux I prefer to statically most of the libraries, so that the binary can work on as many systems as possible, but SCons didn't support that (or made it hard to do) and I ended up writing a makefile for that task.

So now I stick with plain Makefiles, which I guess is low-level nowadays, but at least it gives you full control over what happens (and easier to debug when something isn't working right), and it doesn't bother me to have umpteen different makefiles for different platforms.

Ideally I'd like to see someone think up a much better approach for C/C++ compiling that would greatly simplify library use, going as far as new language constructs if necessary, and definitely needing a much better linker. That is my pipedream anyway :-)

[Graf Zahl]

RjY said:

but what do you suggest as an alternative?

I believe CMake has been suggested several times before. It sure works fine for ZDoom.

[Quasar]

I don't know anything more about CMake than I know about Automake. I just want to add a library to my project, not start over from scratch and spend a solid month learning (and probably fighting with) something new.