help-octave
[Top][All Lists]
Advanced

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

Re: 3.3.54+, mkoctfile, header files?


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:
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.

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.
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?

I agree it should not be run for each make. But I think it should be run for each autogen.sh.
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?

But then it must be printed at a prominent place, so that it is easy to spot.
jwe
Kai


reply via email to

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