[Top][All Lists]

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

Re: [PATCH 3/3] gnu: Add octave and dependencies

From: John Darrington
Subject: Re: [PATCH 3/3] gnu: Add octave and dependencies
Date: Sun, 26 Jan 2014 08:38:16 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Sat, Jan 25, 2014 at 09:41:32PM +0100, Ludovic Court??s wrote:
     John Darrington <address@hidden> skribis:
     > On Sat, Jan 25, 2014 at 05:42:17PM +0100, Andreas Enge wrote:
     >      On Sat, Jan 25, 2014 at 05:14:57PM +0100, John Darrington wrote:
     >      > The octave build system is rather naive.  These propagated inputs 
don't actually
     >      > *need* to be present at configure/build time.  But the 
./configure (rather stupidly IMO)
     >      > checks for their presence, and turns off the relevant features if 
they are not found.
     >      > Therefore, one must declare them as native-inputs just to keep 
./configure happy AND
     >      > as propagated inputs because they are called in a pipe from the 
octave program itself.
     >      Would it be reasonable to patch the lines in which external 
programs are
     >      called, replacing the program name by its complete path with a 
     >      (substitute*)?
     >      Then one would not need to propagate the inputs.
     > I don't think that will work.
     I think it would.  If there???s a line like:
       execlp ("makeinfo" ...);
     patching that to, say:
       execl ("/.../bin/makeinfo" ...);
     will definitely work.  (This is what Octave???s build system should be
     doing, actually.)
     (As an example, see how mingetty is patched to refer to a specific
     ???login??? program, in admin.scm.)
I think I see where you are coming from.  If we did what you suggest, then we 
could remove
makeinfo et al from propagated-inputs, but we would have to add them to inputs 
to native-inputs).

So it would not reduce the total number of "inputs".  Further, it would mean we 
would have
to devise a number of potentially complicated patches, which we would be 
condemned to
maintain.  Further, it seems to me, to be a bit deceptive.  By removing 
makeinfo from
propagated-inputs we are pretending that makeinfo does not need to be installed 
along with
octave, whereas in fact, it does (if one wants to read the manual from within 
As I understand it, a propagated input means that X must always be installed 
with Y.

What benefit does this proposal bring us?


PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See or any PGP keyserver for public key.

Attachment: signature.asc
Description: Digital signature

reply via email to

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