Oh, thanks! I think I get it now. I really appreciate it!

In my previous gl.h example that I stole from a previous use of mine, it will still run through when gl.h isn't available. Here's a modified example for that too (dropping some of the things you likely don't need):

Quote: Original post by Null and VoidNow we must run aclocal again and tell it to include the "m4" subdirectory: aclocal -I m4

To properly set up a separate m4 subdierctory you should really do the following.

(1) Add the stanza

ACLOCAL_AMFLAGS = -I m4

to the top-level Makefile.am and

(2) Change your autogen.sh/bootstrap/Makefile.cvs to just contain the line

autoreconf -ivf

Between those two rules the autoconf/automake suite will take care of generating the right rules so that the right stuff will automatically be remade when dependencies are outdated. If you just run the commands manually (or use explicit regeneration commands instead of autoreconf) you will run into bizarre and hard-to-debug problems.

I would also suggest using the ax_check_gl.m4 macro from the autoconf archive instead of writing your own set of detection instructions, since it's been tested by many others and has some corner case tests that will aid portability.

Quote: Original post by Sydian
is there an easy way to have it put intermediate build files in a different directory than the source code, or is this not commonly done?

What you should do is not build in your source directory at all.

If you generate your configure file in the source directory, you can go to a completely different place and run it, then run make there. If you've set up all your .am files properly it'll just work. The autotools were designed this way so that you could mounts the source on a read-only partition and build for multiple platforms from a single source image.

The next thing to do is to do is a "make dist" from the build directory. This will generate a source tarball that you should move to yet another location, untar, and do a ./configure && make to make sure all your dist_ targets are set correctly. If you plan to distribute your software you'll probably want to distribute sources as well (not just expect people to check your source out of SVN, and source distribution is generally required for GPL'd software). Some of the dist_ targets for data can get a little tricky so it's a good idea to do this test once in a while.

Finally, if you want to target a Linux audience, you'll want to package your binaries using either or both DEB and RPM formats. That's another story, but both of them normally build on the autotools, and both require that the software be installable in non-standard places, so you'll want to make sure everything builds and installs when DESTDIR is set to some value such as /tmp.

Quote: Original post by Bregma
What you should do is not build in your source directory at all.

I'm following Null and Void's tip about using a directory called "build", so I have ./data ./build and ./src in the top-level. Is this what you mean?

Quote: Original post by Bregma
The next thing to do is to do is a "make dist" from the build directory. This will generate a source tarball that you should move to yet another location, untar, and do a ./configure && make to make sure all your dist_ targets are set correctly. If you plan to distribute your software you'll probably want to distribute sources as well (not just expect people to check your source out of SVN, and source distribution is generally required for GPL'd software). Some of the dist_ targets for data can get a little tricky so it's a good idea to do this test once in a while.

Sorry for being a newbie, but what are "dist_" targets? Do you mean like "odysi_(PROGRAMS/etc.)" (since my project is called "odysi")?

Quote: Original post by Bregma
Finally, if you want to target a Linux audience, you'll want to package your binaries using either or both DEB and RPM formats. That's another story, but both of them normally build on the autotools, and both require that the software be installable in non-standard places, so you'll want to make sure everything builds and installs when DESTDIR is set to some value such as /tmp.

Is "DESTDIR" the thing you specify with --prefix= during configure? If so, then it does seem to work fine from non-standard directories. I do hope to package it in both RPM and DEB one day, but I don't think I'm ready for that yet.

Quote: Original post by Sydian
Sorry for being a newbie, but what are "dist_" targets? Do you mean like "odysi_(PROGRAMS/etc.)" (since my project is called "odysi")?

There are probably files that do not need to be built but need to be installed, and must be included in a source distribution. Those files need to be specified somewhere in a Makefile.am and have both installation and distribution rules associated with them

A good example of such a file would be a data file, which is probably what you have in your data subdirectory. You should have a rule such as the following in your data/Makefile.am.

odysidatadir = ${datadir}/odysidist_odysidata_DATA =   datafile1.dat   datafile2.dat

What this will do is create two special rules in the generated Makefile. One, generated by the odysidata_DATA, will install the data files during a make install, and in this case that will be to ${prefix}/share/odysi (and ${prefix} defaults to /usr/local or whatever is set in thye --prefix argument to ./configure). The second rule, generated by the dist_ prefix, will make sure the data files get rolled into the source tarball during a make dist.

To test that everything works, you should run a make dist, copy the source tarball to a new machine, do the autogen.sh/configure/make/make install, and then run the program as a different user. I realize hobbyist developers don't usually have the resources to do that (expecially now that sourceforge got rid of its compile farm) but that's how professional free software developers do release testing.

Quote: Is "DESTDIR" the thing you specify with --prefix= during configure? If so, then it does seem to work fine from non-standard directories. I do hope to package it in both RPM and DEB one day, but I don't think I'm ready for that yet.

Nope, DESTDIR is set when you run make. It gets set by the dpkg-buildpackage or rpmbuild commands. You would use it explicitly like this.

make install DESTDIR=/tmp/odysi

and you will find in /tmp/odysi an image of what would normally be installed in /. You can test your make install without being root. It does this because automake will quietly prepend $(DESTDIR) to the start of every installation path, and the value of DESTDIR is by default the empty string.

So, something like the like the above special data directory, ${odysidatadir}, would end up being ${DESTDIR}${prefix}/share/odysi, where ${prefix} is set to the value of --prefix in ./configure (default /usr/local) and ${DESTDIR} is set by your package manager build process or manually during installation testing.

You will find that dpkg-buildpackage will set DESTDIR to ${top_srcdir}/debian/tmp, which is inside the project surce tree. rpmbuild will use a subdirectory of %{BuildRoot}, which is outside of the source tree in a separate RPM build area. Either way, if your build works fine when you test this by hand, it will likely work without trouble when using a package management system.

I was able to implement the OpenGL macro from the web site, changed the autogen.sh to use autoreconf, and added the dist targets for data. I assume I don't need a dist target for the program, as it seemed to work without it when I tried "make dist" and then installed it from the generated tar file.

I was wondering what exactly goes into each of the GNU files (AUTHORS, ChangeLog), etc. I mean, it seems obvious, but is there a standard format? My project isn't a GNU project, but I don't think it could hurt to try and follow standards whenever possible.

COPYING simply contains your project's license so use that without changes. NEWS and AUTHORS are pretty much free-form but usually stick to the classic 78 characters max width. NEWS summarises the most important (user-visible) changes for each release. AUTHORS lists everyone who contributed on the project. INSTALL is also free-form, but often the standard and boilerplate GNU INSTALL is used.

ChangeLog does have a standardized layout. The easiest way to get a good ChangeLog is to generate one automatically from your versioning system logs. For Subversion there's the svn2cl command.

[Edited by - Sander on June 7, 2008 2:19:40 AM]

Quote: Original post by Sander
For Subversion there's the svn2cl command.

Thanks for the great tip! I found out on my own the format of ChangeLog, and I was put off by the idea of having to generate that kind of documentation on my own, but this tool is a life-saver.