[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: aclocal problem
Re: aclocal problem
Wed, 21 Sep 2005 10:05:51 +0000
> here is an explanation of your problem: sntp/libopts is a subdir
> of both of the packages: ntp-4.0.2b and ntp-4.0.2b/sntp.
> So if you run automake in both of these projects, both runs will
> generate sntp/libopts/Makefile.in.
Yes, which I agree is probably wrong, but at this time I want to allow
people to build ntp and not build sntp. I may have to change my mind
on this one!
> Well, this is consitent with the fact that both ./configure and
> sntp/configure will generate sntp/libopts/Makefile.
> To fix this, it's enough to delete (comment out) the line
> from m4/libopts.m4 (but not from sntp/m4/libopts.m4 !).
That will be Ugly, but I'll talk to Bruce about how we might do this.
If this is what we need to do, I suspect we'll have a 2nd argument to
the LIBOPTS_CHECK macro.
> (Automake processes as config files which have a corresponding .am file.)
> But sntp/libopts is still listed in DIST_SUBDIRS in the root Makefile.
> I don't think this is healthy, so I'd delete it.
> Actually, I think it's better if define DIST_SUBDIRS implicitly, like
> if WITH_ARLIB
> SUBDIR_arlib = arlib
> if WITH_SNTP
> SUBDIR_sntp = sntp
> if NEED_LIBOPTS
> ## We have to omit this from DIST_SUBDIRS, it is handled by the
> ## sntp package.
> ## HACK: this is achieved by using an AC_SUBSTed variable, which is
> ## not known statically.
> SUBDIR_libopts = $(LIBOPTS_DIR)
> SUBDIRS = \
> $(SUBDIR_libopts) \
> scripts \
> include \
> ElectricFence \
> $(SUBDIR_arlib) \
> libntp \
> libparse \
> ntpd \
> ntpdate \
> ntpdc \
> ntpq \
> parseutil \
> adjtimed \
> clockstuff \
> kernel \
> $(SUBDIR_sntp) \
But this solution will only work if we *always* build sntp, as otherwise
sntp/libopts/Makefile will not be generated. Again, this may be what I
have to do.
> I have noticed that libopts/Makefile.am contains
> MAINTAINERCLEANFILES = Makefile.in
> I think this is unfortunate: according to the Coding Standards,
> you should still be able to run ./configure after running
> "make maintainer-clean".
> I understand that there is a need for a target which would bring
> the tree back to the state when it was checked from the CVS, but that
> should have a different name, eg. "make mrproper" or "bootstrap --clean".
> Or you can try to change the GCS that the current definition of
> maintainer-clean should be changed. Such a change would be nice, but
> might be actually a lot of work.
That's for Bruce to decide, I suspect.
> Have a nice day,
You too, and thanks very much!