[m-dev.] Almost ready to merge the update_boehm branch
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
> >+ 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
> >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.
More information about the developers