Re: Including foreign makefiles

[Adam C Powell IV]

Tom Tromey wrote:

> >>>>> "Adam" == Adam C Powell IV <address@hidden> writes:
>
> Adam>    * hard-code the variable I had hoped to get from the foreign
> Adam>    makefile, which will break if it differs from platform to
> Adam>    platform or machine to machine.
>
> Adam>    * give up on cross-platform and hand-create .la files for the
> Adam>    Debian packages of the foreign libs (I maintain that
> Adam>    package), which will only allow linking against the
> Adam>    Debian-packaged version of the toolkit.
>
> You forgot some options.  For instance you could handle this in
> configure.in by scanning the Makefile and generating a series of
> AC_SUBSTs.

True, but there are three more levels of includes after the first ones,
and bits of the PETSC_*_LIB variables are scattered across five files.  A
bit annoying.

But I have another solution, see below.

> Adam> Given that upstream (of the foreign library package with the
> Adam> makefile I'd like to include) is reluctant to even *version*
> Adam> their libraries, or to install anything in standard places, I'm
> Adam> quite certain they'd never accept the enormous patch required to
> Adam> automake/libtoolize their tree.
>
> This kind of thing says "configure" to me.
>
> Remember, the automake `include' is compile-time -- it happens when
> you run automake.  But what you really want is something
> platform-specific, meaning a "runtime" (when the user types "make")
> test.  Runtime test == configure.

Hmm, the "include" line seems to be copied verbatim into the Makefile.in,
so maybe when automake doesn't find the file, it gives up and copies it?

You're right, I want configure to be able to discover these things.  But
having upstream libtoolize would help a lot, because I could just link to
libpetscts.la and have that tell libtool where to get everything else.

Tom Tromey wrote:

> I realize it is annoying when your particular
> problem is hard to solve, but it is hardly automake's fault that it
> doesn't already account for a situation that is so rare that it hasn't
> come up once in five years.

I'm sorry, I wasn't in a good mood when I wrote that, and it showed.
I'll try to substitute healthier forms of stress release for flamage in
the future.  Apologies to the list.

So, here's the current workaround:

   * Copy the distdir, dist and distcheck targets from a Makefile.in into
     Makefile.am and rename them to mydistdir, mydist and mydistcheck.
     Then get rid of the automake run in mydistdir.

Running automake still gives the error return, which breaks some other
targets, but at least that doesn't prevent new tarball creation using
"make mydistcheck".  The vast majority of users will probably not have to
make against an automake-using target.  And automake still doesn't stop
autogen, which is good.

Thanks and apologies again,

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

          Welcome to the best software in the world today cafe!