Hello Joost, * Joost Kraaijeveld wrote on Wed, Dec 03, 2008 at 09:09:58PM CET: > On linux everything works as advertised: "../configure; make" and > everything runs/works (I do an out-of-tree build). > > On Windows however, when I do a "make" after running "../configure", > "configure" is run again as part of the "make" process.
That's the first issue. Most likely due to messed up time stamps, maybe due to the packing/unpacking process? w32 file systems may have different time stamp granularity or so. But with a correctly packaged tarball, I don't think this should happen. > During that > process (the second run of configure) it changes all the aclocal.m4, > Makefiles.in files and the configure script in the source tree. In that > process it loses all the non-default (?) macros that are in the > aclocal.m4 files ( macros for wxWidgets an Boost) and the configure > fails miserably. This is the second issue. It can have several reasons: - the package requires (typically newer) autotools releases than are available on the system. If this is the case, then the required versions should be annotated in configure.ac (with AC_PREREQ and AM_INIT_AUTOMAKE), so that older versions fail reliably with exit status 63. That will then fix the rebuild process to ignore this. - there are third-party macros needed for regenerating files which are either not packaged with your package, or not found by aclocal. The solution to the former is typically, to install them in m4/ (which can be done with new 'aclocal --install' if AC_CONFIG_MACRO_DIR([m4]) is used in configure.ac), the solution to the latter is to add ACLOCAL_AMFLAGS = -I m4 to the toplevel Makefile.am file. - Last but not least, of course you might hit a backward compatibility issue in an autotool, or the package or some used macro relies on some undocumented semantics that are not preserved across versions. I might have forgotten to list more here. > If I than do a revert from SVN (restore all the changed files but > WITHOUT removing the freshly generated Makefiles in the build tree) , > *don't* run configure but run make immediately , it *again* starts a > "configure" but this time it does *not* lose the macros and the build > succeeds, be it that I have to repeat this procedure for every one of > the 3 "sub configures". Well, whether any or all of the files are regenerated, depends on the relative time stamps. If the restoration process leaves aclocal.m4 new enough, then it will likely not be regenerated next time. I assume it's this part that is buggy for you. Cheers, Ralf
