bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-libunistring] two ways to use submodules for gnulib


From: Bruno Haible
Subject: Re: [bug-libunistring] two ways to use submodules for gnulib
Date: Fri, 1 May 2009 19:02:29 +0200
User-agent: KMail/1.9.9

Paolo Bonzini wrote:
> at least it allows me to reconstruct the public tarballs.

That is all that you want? I'll store the reference like this:

*** version.sh.orig     2009-05-01 18:46:48.000000000 +0200
--- version.sh  2009-05-01 18:46:32.000000000 +0200
***************
*** 1,3 ****
--- 1,6 ----
  # Version number and release date.
  VERSION_NUMBER=0.9
  RELEASE_DATE=2009-04-26      # in "date +%Y-%m-%d" format
+ 
+ # Version of gnulib that was used in this release.
+ GNULIB_GIT_COMMIT=13a006f97fca894168e4c1aedfa780f83717c78c

> I would like to checkout
> libunistring at April 30th 2009 and see what the corresponding gnulib
> HEAD was

The answer is: You need the gnulib HEAD from Aprit 30th 2009 as well.
This is implicitly clear from the comments in autogen.sh.

> >    (Is that the reason why in your second recipe, you limit the scope of
> >    the .gitmodules file and the gnulib submodule to the 'releases' branch?)
> 
> Yes, this limits the presence of submodules to the releases branch and
> hence to tags.

OK, but then I don't see the point of using git submodules for this
feature. If I did, then
  - I would have to update regularly the reference to the latest gnulib,
    whereas the rule "newest libunistring needs newest gnulib" already
    says everything.
  - The git history would become nonlinear and confusing, with releases
    occurring on a particular branch only.
  - Users of my development tree would have to learn about git submodules.

I'm committing this to version.sh and HACKING.

Bruno


*** version.sh.orig     2009-05-01 19:00:51.000000000 +0200
--- version.sh  2009-05-01 18:46:32.000000000 +0200
***************
*** 1,3 ****
--- 1,6 ----
  # Version number and release date.
  VERSION_NUMBER=0.9
  RELEASE_DATE=2009-04-26      # in "date +%Y-%m-%d" format
+ 
+ # Version of gnulib that was used in this release.
+ GNULIB_GIT_COMMIT=13a006f97fca894168e4c1aedfa780f83717c78c
*** HACKING.orig        2009-05-01 19:00:51.000000000 +0200
--- HACKING     2009-05-01 19:00:14.000000000 +0200
***************
*** 36,46 ****
--- 36,54 ----
        http://www.perl.org/
  
    * Either an internet connection or a recent copy of GNU gnulib.
+     In order to work with the HEAD of libunistring development, you need the
+     HEAD of the gnulib development.
+     In order to work with the version of libunistring at a given date, you 
need
+     the version of gnulib of the same date.
+     In order to work with a released tarball of libunistring, you need the
+     particular version of gnulib which is indicated in the GNULIB_GIT_COMMIT
+     variable in version.sh.
      + Homepage:
        http://www.gnu.org/software/gnulib/
  
  And, of course, the packages listed in the DEPENDENCIES file.
  
+ Then you can run the 'autogen.sh' script 
  
  Sources
  =======




reply via email to

[Prev in Thread] Current Thread [Next in Thread]