[m-dev.] Almost ready to merge the update_boehm branch

Paul Bone paul at bone.id.au
Thu Sep 24 19:52:30 AEST 2015

On Thu, Sep 24, 2015 at 06:02:18PM +1000, Julien Fischer wrote:
> Hi Paul,
> On Thu, 24 Sep 2015, Paul Bone wrote:
> >On Wed, Sep 23, 2015 at 11:54:31AM +1000, Julien Fischer wrote:
> >>
> >>Hi Paul,
> >>
> >>On Wed, 23 Sep 2015, Paul Bone wrote:
> >>
> >>>I'm almost ready to merge the upgrade_boehm branch.
> >>>
> >>>Once it's merged you will need to use the prepare.sh script to prepare your
> >>>checkout before running configure (see below).
> >>
> >>When I last looked at this branch there seemed to be a bunch of new tool
> >>dependencies, for example libtool.  Is this still the case?  If so, what
> >>are the new dependencies?
> >>
> >
> >I've fixed the other issues except libtool.  I have two options, neither is
> >great.
> >
> >+ Commit generated files to git such as the configure script and Makefiles,
> >  note that that's the generated script, not configure.ac.
> >
> >+ Attempt to generate these files, which ideally should only happen for
> >  people checking out from git, not the source distribution.  This adds the
> >  dependency of libtool.
> >
> >So why this situation? what's different now that I'm updating boehm_gc?
> >Nothing, libatomic_ops has previously also depended on libtool.  We just
> >used to commit generated files to git/CVS in the libatomic_ops directory.
> >Maybe we made a decision to do this or maybe it was by accident.  I suspect
> >an accident because I try to avoid committing generated files.
> It was probably a result of the fact that we used to import the Boehm GC
> stable tarballs which already had their configuration files generated.
> (The fact that this avoided mucking about with libtool was just a happy
> accident!)
> >So is it bad to depend on libtool for developers only?  This does not affect
> >anyone building from the source distribution.  Is it okay if we just call it
> >with glibtoolize or whatever you said it was called on, was it OS X?
> libtoolize is a separate thing from libtool: is the new dependency only
> on the latter or are both programs required?

I don't know.  I will try to understand / find out.  Urgh, autotools.

> The issue on OS X is that there is already a separate utility name
> libtool.  macports renames both the executables in the libtool package
> in order to avoid clashing with this.

Ah okay.

Paul Bone

More information about the developers mailing list