Re: aclocal problem

[Harlan Stenn]

Hi Stepan,

> 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.

Yes...

> 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.

OK...

> To fix this, it's enough to delete (comment out) the line
> 
>       AC_CONFIG_FILES(AO_Libopts_Dir/Makefile)
> 
> 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
> this:
> 
> if WITH_ARLIB
>   SUBDIR_arlib = arlib
> endif
> if WITH_SNTP
>   SUBDIR_sntp = sntp
> edif
> 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)
> edif
> SUBDIRS = \
>       $(SUBDIR_libopts) \
>         scripts \
>         include \
>         ElectricFence   \
>         $(SUBDIR_arlib) \
>         libntp  \
>         libparse        \
>         ntpd    \
>         ntpdate \
>         ntpdc   \
>         ntpq    \
>         parseutil       \
>         adjtimed        \
>         clockstuff      \
>         kernel  \
>         $(SUBDIR_sntp) \
>         util

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.

> BTW:
> 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!

H