[m-dev.] libatomic_ops submodule

[Zoltan Somogyi]

I have a couple of problems with the new libatomic_ops submodule.

The first problem is that I keep getting this as part of my diffs:

diff --git a/libatomic_ops b/libatomic_ops
--- a/libatomic_ops
+++ b/libatomic_ops
@@ -1 +1 @@
-Subproject commit 137001b1d9bddc0034de887c8e6ebc32893b1821
+Subproject commit 137001b1d9bddc0034de887c8e6ebc32893b1821-dirty

Does anyone know what causes this, and how to stop it, other than
deleting the directory and fetching it again?

The second is that I often change to the library directory by doing
"cd ../libTAB", where TAB is my filename completion character.
That used to work, but now libatomic_ops is also a valid completion
of just "lib". Can we give this directory some name that doesn't
get in the way like this?

Zoltan.

[Paul Bone]

On Mon, Oct 05, 2015 at 07:47:48PM +1100, Zoltan Somogyi wrote:
> I have a couple of problems with the new libatomic_ops submodule.
>
> The first problem is that I keep getting this as part of my diffs:
>
> diff --git a/libatomic_ops b/libatomic_ops
> --- a/libatomic_ops
> +++ b/libatomic_ops
> @@ -1 +1 @@
> -Subproject commit 137001b1d9bddc0034de887c8e6ebc32893b1821
> +Subproject commit 137001b1d9bddc0034de887c8e6ebc32893b1821-dirty
>
> Does anyone know what causes this, and how to stop it, other than
> deleting the directory and fetching it again?

Because some generated files are kept in the libatomic_ops directory to
avoid a dependency on libtool, when they are regenerated for whatever reason
git recognises that you have uncommited changes there.

If you "deinitialise" your git submodules

$ git submodule deinit -f .

WARNING: you will loose unsaved changes in the submodules.

And re-initialise them:

$ ./prepare.sh

Git keeps a cache of the remote repository. However it check with the
remote to see if there a new changes, but won't need to download the whole
thing again. If you don't want it to use any network access you can edit
prepare.sh and remove the --remote option from "git update".

I realize this isn't ideal, it still adds extra steps to our workflows. An
alternative might be allowing libtool as a dependency.


> The second is that I often change to the library directory by doing
> "cd ../libTAB", where TAB is my filename completion character.
> That used to work, but now libatomic_ops is also a valid completion
> of just "lib". Can we give this directory some name that doesn't
> get in the way like this?

I'm happy to hear suggestions for a new name.

--
Paul Bone

[Peter Wang]

On Tue, 6 Oct 2015 13:20:33 +1100, Paul Bone <***@bone.id.au> wrote:
> On Mon, Oct 05, 2015 at 07:47:48PM +1100, Zoltan Somogyi wrote:
> > I have a couple of problems with the new libatomic_ops submodule.
> >
> > The first problem is that I keep getting this as part of my diffs:
> >
> > diff --git a/libatomic_ops b/libatomic_ops
> > --- a/libatomic_ops
> > +++ b/libatomic_ops
> > @@ -1 +1 @@
> > -Subproject commit 137001b1d9bddc0034de887c8e6ebc32893b1821
> > +Subproject commit 137001b1d9bddc0034de887c8e6ebc32893b1821-dirty
> >
> > Does anyone know what causes this, and how to stop it, other than
> > deleting the directory and fetching it again?
>
> Because some generated files are kept in the libatomic_ops directory to
> avoid a dependency on libtool, when they are regenerated for whatever reason
> git recognises that you have uncommited changes there.

The only file that is untracked for me is 'libtool'.
Isn't it a matter of adding it to .gitignore?

There is git status --ignore-submodules=untracked
and the corresponding configuration file option.

We might also add this to .gitmodules:

[submodule "libatomic_ops"]
path = libatomic_ops
url = ../libatomic_ops.git
branch = release-7_4-mercury
ignore = untracked

> > The second is that I often change to the library directory by doing
> > "cd ../libTAB", where TAB is my filename completion character.
> > That used to work, but now libatomic_ops is also a valid completion
> > of just "lib". Can we give this directory some name that doesn't
> > get in the way like this?
>
> I'm happy to hear suggestions for a new name.

The obvious name is "atomic_ops". It would be nice to keep all the
names the same (upstream repo, our repo, submodule name, directory name,
symlink) but we already have a difference for "boehm_gc".

Peter

[Zoltan Somogyi]

On Tue, 6 Oct 2015 14:55:12 +1100, Peter Wang <***@gmail.com> wrote:
> > I'm happy to hear suggestions for a new name.
>
> The obvious name is "atomic_ops". It would be nice to keep all the
> names the same (upstream repo, our repo, submodule name, directory name,
> symlink) but we already have a difference for "boehm_gc".

Actually, I think an even more obvious name is libatomic_ops itself,
but one level down, in a new directory maybe named "submodules".

Zoltan.

[Sebastian Godelet]

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

Cheers,

Sebastian

> -----Original Message-----
> From: developers [mailto:developers-***@lists.mercurylang.org] On
> Behalf Of Paul Bone
> Sent: Tuesday, October 6, 2015 10:21 AM
> To: Zoltan Somogyi
> Cc: developers
> Subject: Re: [m-dev.] libatomic_ops submodule
>
> On Mon, Oct 05, 2015 at 07:47:48PM +1100, Zoltan Somogyi wrote:
> > I have a couple of problems with the new libatomic_ops submodule.
> >
> > The first problem is that I keep getting this as part of my diffs:
> >
> > diff --git a/libatomic_ops b/libatomic_ops
> > --- a/libatomic_ops
> > +++ b/libatomic_ops
> > @@ -1 +1 @@
> > -Subproject commit 137001b1d9bddc0034de887c8e6ebc32893b1821
> > +Subproject commit 137001b1d9bddc0034de887c8e6ebc32893b1821-dirty
> >
> > Does anyone know what causes this, and how to stop it, other than
> > deleting the directory and fetching it again?
>
> Because some generated files are kept in the libatomic_ops directory to
> avoid a dependency on libtool, when they are regenerated for whatever
> reason
> git recognises that you have uncommited changes there.
>
> If you "deinitialise" your git submodules
>
> $ git submodule deinit -f .
>
> WARNING: you will loose unsaved changes in the submodules.
>
> And re-initialise them:
>
> $ ./prepare.sh
>
> Git keeps a cache of the remote repository. However it check with the
> remote to see if there a new changes, but won't need to download the whole
> thing again. If you don't want it to use any network access you can edit
> prepare.sh and remove the --remote option from "git update".
>
> I realize this isn't ideal, it still adds extra steps to our workflows. An
> alternative might be allowing libtool as a dependency.
>
>
> > The second is that I often change to the library directory by doing
> > "cd ../libTAB", where TAB is my filename completion character.
> > That used to work, but now libatomic_ops is also a valid completion
> > of just "lib". Can we give this directory some name that doesn't
> > get in the way like this?
>
> I'm happy to hear suggestions for a new name.
>
> --
> Paul Bone
> _______________________________________________
> developers mailing list
> ***@lists.mercurylang.org
> https://www.mercurylang.org/lists/listinfo/developers

[Paul Bone]

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

[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: ***@bone.id.au
> To: ***@outlook.com
> CC: ***@runbox.com; ***@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