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