Hi,
thanks for your quick reply.
On Wed, Mar 3, 2010 at 1:54 PM, Eric Blake <eblake@xxxxxxxxxx> wrote:
> According to Steffen Dettmer on 3/3/2010 4:31 AM:
> > I have a new dir with dir/configure.in and added it to
> > ./configure.in's AC_CONFIG_SUBDIRS([dir]).
>
> You may want to consider renaming all of those to configure.ac instead.
> That has been the recommended practice for several years now.
Ohh, does this have an effect? We also have .m4 files included. I
feel `.in' for input files more straightforward and CVS does not
handle renaming files.
> > In Makefile.am I have
> > SUBDIRS=@subdirs@ admin
>
> so that you are passing literal subdir names to SUBDIRS rather than values
> substituted at configure time? The automake manual has a node on
> conditional subdirectories.
Ohh no, sorry, they are not conditional.
The SUBDIRS=@subdirs@ is just there to avoid the redundancy to
AC_CONFIG_SUBDIRS (in almost all our cases, SUBDIRS is the same
as AC_CONFIG_SUBDIRS plus admin directory).
I think using @subdirs@ cannot be the problem because in the new
directory not even configure is created from configure.in when
running make.
The problem is when a new package (let's say a lib) is added to
the super-package, the super-package configure has a new subdir
to configure recursively.
Maybe I tell the high-level-problem with other words:
After cvs update, when a new sub-package was added and
AC_CONFIG_SUBDIRS was extended, make fails. So each user must
pre-conf (autoreconf or so) the srcdir and re-configure each
builddir (uncomfortable and takes much time and touches all
config.h) and then re-make everything (takes much time again).
Is there some trick / way to improve on that?
Our current workaround has
recheck-recursive:
@echo "In directory `pwd`:"
../../configure `cat .config-opts`
in toplevel Makefile (to be run by `for d in * ... make -C $d recheck'),
which works automatically (but still consumes much time, but can be run
in background).
oki,
Steffen
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
