Re[2]: [Gc]: Dependency tracking for configuration macros

Ivan Maidanski ivmai at mail.ru
Fri Sep 25 10:51:44 PDT 2009


Hi!

Petter Urkedal <urkedal at nbi.dk> wrote:
> 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.)

Ok. Checked it in.

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

Ok. Prepare the patch for it.

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

Ok. 1. Prepare the patch for it.

2. Post my the regenerated files (as if the above patches applied).

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

Let this be info for Hans...

Bye.


More information about the Gc mailing list