Re: aclocal problem

[Stepan Kasal]

Hello Harlan,

On Wed, Sep 21, 2005 at 10:05:51AM +0000, Harlan Stenn wrote:
> > 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,

it is wrong.

> but at this time I want to allow people to build ntp and not build sntp.

I understood that, and I thought my advice maintained that.
But I'm afraid I have made some bugs.

> 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 didn't thought so, but I was prtobably wrong.
Please note that sntp/libopt was part of SUBDIRS in the top Makefile, so
make would recurse there and build the library.

Unfortunately, that Makefile would be generated by sntp/configure, which
would mean that you'd have to run sntp/configure, even though you are not
going to build it.  So you'd have to replace this:

case "$MAKE_SNTP" in
 '') ;;
 *)
    AC_CONFIG_SUBDIRS(sntp)
    ;;
esac

by a mere "AC_CONFIG_SUBDIRS(sntp)".  Would that be OK with you?

Let me recap:
there are actually three ways to define the tree structure:

1) AC_CONFIG_FILES(*/Makefile) declares which directories belong to this
   package

2) SUBDIRS = ...  used for build

3) DIST_SUBDIRS = ...  used for "make dist"

ad 1) I believe these cannot overlap.  The race condition you reported
cannot be handled reasonably.  (Which automake call will be the last one
to generate libopt/Makefile.in.)
So you _have to_ remove one of the two instances of:
        AC_CONFIG_FILES(AO_Libopts_Dir/Makefile)

ad 2) I _tried to_ maintain the overlap, as you had it.
But perhaps it's an issue which cannot be easily resolved.

ad 3) I discussed this in my previous mail.  But it seems it doesn't
caused any problem yet, so we can forgot about it for now.

Yet another proposal:
what about having two copies of libopts, one in each package?

Yes, I see, it looks as a waste to have the same lib twice, but
consider this:

Imagine I have a system without libopts installed, and I decide to
install two packages foo and bar, which both use libopts.
Since there is no libopts on the system, each of the package will build
it's own copy of libopts.  Two copies will be installed, yes, but
that's the price.

You declare that sntp and ntp are two autonomous packages.
Each of them has it's own configure script, though both are huge.
You cannot reuse the 90% of one of them in the other one.
That's the way it is, and that's the price you pay for declaring them
as two autonomous packages.

And it should probably be similar with libopts: if the two packages
are really autonomous, then each of them has a right to bring its
own copy of libopts.  If you don't like it, you can put a big educative
warning to the configure, that the user should install autoopts.

Another possibility is to revoke the autonomy of sftp.
IMHO, the "subpackage" feature is meant for distributed "foreign" packages.
If you have contol over both packages, you can use other means to modify
the autoconfigury of the package, so that it makes an integrate part of ntp.

Hope this ideas will inspire you,
        Stepan