Fwd: Re[2]: [Gc] Should libatomic_ops be inside bdwgc?

[Ivan Maidanski]

Hi Petter,

In bdwgc dir, I ran "autoreconf -vif; ./configure; make check; make maintainer-clean". The following still not removed:
#       Makefile.in
#       aclocal.m4
#       compile
#       config.guess
#       config.sub
#       configure
#       depcomp
#       include/private/config.h.in
#       include/private/config.h.in~
#       install-sh
#       ltmain.sh
#       m4/libtool.m4
#       m4/ltoptions.m4
#       m4/ltsugar.m4
#       m4/ltversion.m4
#       m4/lt~obsolete.m4
#       missing

The similar for libatomic_ops:
#       Makefile.in
#       aclocal.m4
#       compile
#       config.guess
#       config.sub
#       configure
#       depcomp
#       doc/Makefile.in
#       install-sh
#       ltmain.sh
#       m4/libtool.m4
#       m4/ltoptions.m4
#       m4/ltsugar.m4
#       m4/ltversion.m4
#       m4/lt~obsolete.m4
#       missing
#       src/Makefile.in
#       src/config.h.in
#       src/config.h.in~
#       tests/Makefile.in
#       tests/list_atomic.c

Regards.

15 08 2011, 12:48 Ivan Maidanski <ivmai at mail.ru>:
> Hi Petter,
> 
> I've committed your changes to libatomic_ops (with minor additions to .gitingore).
> 
> About make maintainer-clean: it does not clean /m4 contents. Is it expected?
> 
> Regards.
> 
> 14 08 2011, 15:34 Petter Urkedal <urkedal at nbi.dk>:
> > On 2011-08-12, Petter Urkedal wrote:
> > > On 2011-08-12, Ivan Maidanski wrote:
> > > > Now I have another issue with make distcheck (I have libatomic_ops folder inside bdwgc):
> > > > configure: error: libatomic_ops is required.  You can either install it on your system, or fetch and unpack a resent version into the source directory and link or rename it to libatomic_ops.
> > >
> > > The issue is that distcheck needs everything to be automated, so I think
> > > the option of unpacking libatomic_ops in the source directory has to be
> > > secondary.  We'll need to use a pre-installed one ourselves.  To test
> > > that the other option worked, I passed --without-libatomic-ops and used
> > > the regular build target.
> >
> > I realized that I'm probably working a bit different from you.  When I
> > have several dependent libraries which I work with at the same time, I
> > use a feature of pkg-config (and libtool) which allows linking in one
> > library from the build-directory of the other.  I've done the necessary
> > changes to libatomic_ops and bdwgc and will send you pull requests so
> > you can have a look.  This works by setting
> > PKG_CONFIG_PATH=path-to-libatomic_ops-build-dir/pkgconfig (it's
> > colon-separated if you have several).  pkg-config will then pick up the
> > "-uninstalled.pc" version if present.
> >
> > The different modes of the somewhat bloated libatomic_ops detection in
> > bdwgc can be tested as follows assuming PKG_CONFIG_PATH is set:
> >
> >   * Configure and build libatomic_ops, then configure and distcheck
> >     bdwgc.
> >
> >   * Issue "make install; make maintainer-clean" in libatomic_ops.
> >     Now, bdwgc should pick up the installed version and one can do
> >     distcheck again.  Issue uninstall in libatomic_ops afterwards.
> >
> >   * After an uninstall and maitainer-clean in libatomic_ops, one can try
> >     to link the directory under bdwgc, and run check.  As mentioned
> >     distcheck won't work.  Remove the link and build libatomic_ops again
> >     to get back to "normal".
> >
> > I should mention that the whole "Atomic Ops" section in
> > bdwgc/configure.ac can be reduced to one line,
> > PKG_CHECK_MODULES([ATOMIC_OPS], [atomic_ops])
> > if we skip support extracting/linking libatomic_ops in the source dir.
> > _______________________________________________
> > Gc mailing list
> > Gc at linux.hpl.hp.com
> > http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> >
>