[Gc]: Dependency tracking for configuration macros

Petter Urkedal urkedal at nbi.dk
Fri Sep 25 10:12:10 PDT 2009


On 2009-09-25, Ivan Maidanski wrote:
> Checked in only the first part. Confused with AM_PROG_CC_C_O: in the
> other libatomic_ops files we are using "AM_PROG_CC". Why do we delete
> it in configure.ac?

AM_PROG_CC_C_O subsumes AM_PROG_CC.  The former macro also checks that
the compiler supports -c -o OUTFILE options or equivalent, which is
required here because test_atomic.c is compiled into to different
objects (test_atomic.o and test_atomic_pthreads.o) using different
compiler flags.  (I'm not sure if the macro has a workaround when -o is
unsupported.)
 
> Other questions:
> 1. Why are we using DARWIN_THREADS (and friends) in Makefile.am w/o GC_ (while having them prefixed in configure.ac)?

I guess you are referring to the "if" statements?  These are different
things, and they are defined unprefixed in AM_CONDITIONAL.  They are not
exported to the C code like AC_DEFINE or directly substituted elsewhere
like AC_SUBST.  Therefore they don't escape the project build in any
other way than by the effect they have on the makefiles.

> 2. Is this realy needed: "EXTRA_DIST += libtool.m4"?

I was going to suggest that we remove it along with the file itself.

> > I'm omitting generated files, so this works after "autoreconf -vif".
> 
> Announce the full list (of the auto-generated files), please.

>From libgc:

    Makefile.in
    compile
    config.guess
    config.sub
    configure
    depcomp
    include/private/config.h.in (not in repo)
    install-sh
    ltmain.sh
    missing
    mkinstalldirs

>From libatomic_ops:

    libatomic_ops-1.2/configure
    libatomic_ops-1.2/doc/Makefile.in
    libatomic_ops-1.2/Makefile.in
    libatomic_ops-1.2/src/atomic_ops/Makefile.in
    libatomic_ops-1.2/src/atomic_ops/sysdeps/Makefile.in
    libatomic_ops-1.2/src/config.h.in
    libatomic_ops-1.2/src/Makefile.in
    libatomic_ops-1.2/tests/Makefile.in

Unfortunately, also

    libatomic_ops-1.2/INSTALL

is overwritten, but we can avoid that by adding the "foreign" option to
AM_INIT_AUTOMAKE.

> Hans -
> I guess these ones should be regenerated soon. But what's the policy
> for presence of the auto-generated files in:
> 1. CVS?
> 2. in a tar-ball?
> And, if Makefile should be present (in CVS/tarball), for which target
> it should be generated?

The files generated by autoreconf (thus libtool, autoconf, automake) are
target independent.  Target dependencies are detected by ./configure. 

(My vote FWIW: Option 2.  Pro: Easier for developers.  Con: End users
who build from the repo need the dev tools.)

About the Makefile in the toplevel directory:  Looking at the diff, this
seems to be an outdated version of Makefile.direct.  In that case I
suggest removal.  In any case it is overwritten by ./configure.


More information about the Gc mailing list