|
From: | Kai Habel |
Subject: | Re: 3.3.54+, mkoctfile, header files? |
Date: | Fri, 14 Jan 2011 20:26:40 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100914 SUSE/3.1.4 Lightning/1.0b2 Thunderbird/3.1.4 |
On 14.01.2011 19:58, John W. Eaton wrote:
Since we don't monitor gnulib it is never "save" to pull gnulib. If we pull automatically and the current gnulib repo is "bad" we can always pull a previous version by hand.On 14-Jan-2011, Kai Habel wrote: | On 14.01.2011 19:31, John W. Eaton wrote: |> On 14-Jan-2011, Olaf Till wrote: |> |> | Yes, with a fresh download it works. Thanks. |> |> The thing you needed to fix the filemode.h problem was to run "git |> pull" in the gnulib directory. We don't do that automatically for |> you. |> | Since I fall into this trap from time to time, why don't we? Although gnulib is generally pretty stable even though development is pretty rapid, there is also no way to know in advance when it is "safe" to pull from the gnulib archive. So I'm still not convinced that it would be a good idea to just force an update all the time.
I agree it should not be run for each make. But I think it should be run for each autogen.sh.Also, where does the rule belong? I don't think we should be trying "git pull" everytime make is run. Doing it when autogen.sh is run wouldn't solve a problem like Olaf encountered. Is there a way to (optionally) run a command after hg pull?
But then it must be printed at a prominent place, so that it is easy to spot.Maybe it would be sufficient to check and see whether the gnulib directory is up to date and print a message if it is not?
jwe
Kai
[Prev in Thread] | Current Thread | [Next in Thread] |