Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [hwloc-devel] git / nightly builds
From: Brice Goglin (Brice.Goglin_at_[hidden])
Date: 2013-09-28 08:12:11

Le 28/09/2013 13:30, Jeff Squyres (jsquyres) a écrit :
> Good catch; sorry about that. HWLOC_SVN_R no longer exists (as you
> noted). I just removed that 4th argument to distscript.csh. Now,
> distscript (on master and v1.7) only edits VERSION if snapshot=1 and
> snapshot_version is empty (i.e., if you do "make dist" in a git clone
> instead of running contrib/nightly/make_nightly_snapshot, which will
> edit VERSION before running "make distcheck").

Thanks, things look better now.

> Yes, these are good points. I agree: the system is too complicated right now. :-\
> Let's go through the use cases of what we want:
> 1. "make dist" in a developer's git clone. This should make a "hwloc-<git describe>.tar.*.

This is actually the critical point, see below.

> 2. make a nightly snapshot tarball. The more I think about this, the more I think it's the same as #1, right?

Yes, that's why I didn't understand why the create_tarball script also
modified VERSION to add git describe. These changes should be either
entirely outside of make dist (if we want git describe for nightly but
not for make dist) or entirely inside make dist (if we want for both).

> 3. make a release tarball, "hwloc-major.minor.releasegreek.tar.*".
> Are these the three (or two, if #2 is the same as #1) use cases we want? If so, I can see about making the code simpler -- e.g., I didn't know about overriding the VERSION Makefile macro trick...

Changing VERSION on the command-line doesn't change the lstopo
--version, so it may not be what we really want. Also, if changing the
suffix is just a sed on VERSION file before autogen or configure, it's
fine too.

This all depends on what we really want for (1).
* If we don't do (1), we can remove tons of lines of code from the
configury and just have the nightly and release scripts modify VERSION
before running autogen. Easy.
* If we do (1), that needs much more work.

I actually don't care much about (1), I am used to tarballs without the
SVN revision suffix (not sure why I didn't always get that suffix). I
agree that it's convenient to have the suffix for developer builds (when
you want to compare several of them, when you distribute that tarball
for some reason, etc). But maybe the nightly script is enough for these
cases? Does it work with locally modified trees? Or trees that contain
additional commits? By the way, maybe move that script back from nightly
to dist.

> Yeah, I'm a bit disappointed by the github email service hook (the config is here:; scroll down to "Email"). There's *very* little configuration available:
> - the address to send to
> - an email address secret
> - what address to send from
> There's no option for diffs (!), and no option to customize the mail/subject. :-\
> Do you have a favorite git commit emailing script? We can probably use the generic github "WebHook URLs" hook (at the top of the list) and host the diff-emailing script at IU (or anywhere, actually).

I use the attached one for Open-MX and KNEM. Not sure I tried many of
them, but this one worked fine so far. It generates messages such as:
I don't think it truncates the diff yet. We may want some separators
between commits too. All this shouldn't be hard to configure.