[m-dev.] libatomic_ops submodule

[Sebastian Godelet]

On a related issue, I noticed that in the libatomics_ops/m4 directory, the m4 files are created as symlinks,
which first are not very good supported on Windows,
second point to /usr/share/aclocal/libtool.m4 which doesn't work on Windows,
and third, the links also end up in the ROTD tarball, and thus lead to unpacking errors on Windows,
maybe it would be better to include copies of the files instead of symlinks,
 
cheers, Sebastian
 
> Date: Mon, 12 Oct 2015 15:14:51 +1100
> From: paul at bone.id.au
> To: sebastian.godelet at outlook.com
> CC: zoltan.somogyi at runbox.com; developers at lists.mercurylang.org
> Subject: Re: [m-dev.] libatomic_ops submodule
> 
> On Sat, Oct 10, 2015 at 07:57:54PM +0800, Sebastian Godelet wrote:
> > Hello Paul,
> > 
> > I've got a question about libatomic_ops,
> > Wouldn't it be easier to let libatomic_ops be a submodule of boehm_gc and
> > Use `git submodule update --init --recursive' or `git clone --recursive (when initially cloning mercury)'
> > Since the prepare script uses cp on Windows, one must manually update the libatomic_ops/* copied files
> > 
> 
> I considered this when I originally set this up (some time last year).  So I
> don't remember the exact reason I decided against it.  It probably seemed
> more complicated than necessary.
> 
> However one benifit is, as you said, it avoids the symlink/copy problem of
> getting libatomic_ops into the boehm_gc directory.  So I'm happy to give it
> a go.
> 
> Any (reasonable) objections before I start making this change?
> 
> 
> -- 
> Paul Bone
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/developers/attachments/20151012/2a74cbf2/attachment.html>