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

Julien Fischer jfischer at opturion.com
Thu Sep 24 18:02:18 AEST 2015


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?

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.

Julien.



More information about the developers mailing list