The problem with requiring auto* tools boils down to about four + thirteen
lines in Makefile.in created by automake... and one missed commit. (I know,
it sounds like a nursery rhyme).
But where do they come from?? And why??? And how do you fix them????
Well, here's a partial answer... It's this block of generated lines in
Makefile (i.e. ./configure put 'em there, not anything we did purposely):
$(srcdir)/Makefile.in: Makefile.am $(top_srcdir)/configure.in
$(ACLOCAL_M4)
cd $(top_srcdir) && \
$(AUTOMAKE) --gnu Makefile
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
cd $(top_builddir) && $(SHELL) ./config.status $@
$(am__depfiles_maybe)
$(top_builddir)/config.status: $(srcdir)/configure
$(CONFIG_STATUS_DEPENDENCIES)
$(SHELL) ./config.status --recheck
$(srcdir)/configure: $(srcdir)/configure.in $(ACLOCAL_M4)
$(CONFIGURE_DEPENDENCIES)
cd $(srcdir) && $(AUTOCONF)
$(ACLOCAL_M4): configure.in acinclude.m4
cd $(srcdir) && $(ACLOCAL) $(ACLOCAL_AMFLAGS)
As near as I can tell, this block of somewhat circular lines says...
1. Gee, if any of these guys (Makefile.am, configure.in or aclocal.m4) are
newer than Makefile.in, then rebuild Makefile.in
2. If any of these guys (Makefile.in or config.status) are newer than
Makefile, then rerun ./configure (that's what config.status does)
3. If configure is newer than config.status, rerun ./configure once again
4. If configure.in or aclocal.m4 is newer than configure, then run autoconf
to make a whole new configure.in (which will cause problems on the next run,
naturally)
5. If configure.in or acinclude.m4 is newer than aclocal, then make aclocal.
So, if you make changes in the base files (not the generated ones invoked by
users running ./configure and make) - it will rebuild them in the proper
sequence to protect you. And this shouldn't require the auto* tools unless
we really need 'em (i.e. if you make changes in the base files, you better
have the tools).
Ok, the root problem seems to be that we forgot (we=me) to commit the update
to aclocal.m4 last time we (we=me) updated acinclude.m4.ntop. That's what
triggers the forced rebuild. Anyway, once it rebuilds aclocal.m4,
everything is (eventually) fine, because it achieves the same result as if I
had committed the aclocal.m4 file.
But it does require you have the auto* tools, even when you don't think you
should have to have 'em. But with the 'older' version of aclocal, you do
need to rebuild...
So all I have to do is to commit a recreated aclocal.m4 ... this makes it
more recent than the other files and stops the problem.
Also, with those lines, if you have just the right (or wrong) set of time
stamps on your files, you can end up running configure five times (once
manually and then a bunch more just stream past on the terminal) - AND I'VE
SEEN IT DO THAT, especially building the rpms...
Now, Luca and Rocco's changes over the weekend will fix another block of
situations - however, we still have one big problem with these generated
lines in Makefile.in:
ACLOCAL = @ACLOCAL@
AUTOCONF = /bin/sh /home/deri/network/ntop/missing --run echo
AUTOMAKE = /bin/sh /home/deri/network/ntop/missing --run echo
AUTOHEADER = @AUTOHEADER@
Luca/Rocco cleverly told make to check and see if 'echo' is missing instead
of, say, autoconf. Well, unless your system is really, badly broken, echo
is just fine and we don't try to rerun autoconf.
What's the problem? Well, first off they have Luca's directory structure in
them. So unless all of you go out and change your computer accounts, we've
got one kind of problem.
Second, these lines are automatically generated to fill a critical part of
the auto* tools hierarchy - they run the missing script to make sure all of
the critical files are available. The problem is that if they're not, they
can invoke pieces of the auto* tools, which is trouble if you don't have,
say, aclocal installed, and is what we DO NOT want to do unless we
absolutely have to... These lines are ideally automatically generated to
catch updates by a developer to the various base files and, well, fake out
the other piece. I.e. .../missing --run aclocal should, via this:
aclocal*)
if test -z "$run" && ($1 --version) > /dev/null 2>&1; then
# We have it, but it failed.
exit 1
fi
echo 1>&2 "\
WARNING: \`$1' is missing on your system. You should only need it if
you modified \`acinclude.m4' or \`${configure_ac}'. You might want
to install the \`Automake' and \`Perl' packages. Grab them from
any GNU archive site."
touch aclocal.m4
;;
whine at you about aclocal not being installed, tell you, well maybe it
doesn't matter, and then touch the file so that the 13 lines above don't try
to recreate aclocal.m4.
Anyway, Luca/Rocco's stuff means that missing won't be run, and - as a
developer - if you muck with the base files, you better dang well make sure
you manually do the updates. Still, without the fake-out stuff in missing,
the tests above (the 13 lines up top) should catch them until we commit
those fixes and then everyone is going to complain about things not working.
Third, the next time we recreate Makefile.am and thus Makefile.in we'll lose
the fix.
If we put this block in Makefile.am:
ACLOCAL = /bin/sh ./missing --run echo
AUTOCONF = /bin/sh ./missing --run echo
AUTOMAKE = /bin/sh ./missing --run echo
AUTOHEADER = /bin/sh ./missing --run echo
It will carry forward without anyone's specific directory structure and I
think we have nerdvana. We don't require the auto* tools unless we really
need 'em (i.e. if you make changes in the base files, you better have the
tools).
Anyway, I'm testing the patch across 5 systems and if it works, I'll commit
it. But it's going to take time to uninstall the tools on these systems,
run the tests etc. so be patient...
-----Burton
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop
