guix-devel
[Top][All Lists]
Advanced

[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 
well-chosen
     >      (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.)
     
     WDYT?
     
     (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 
(in 
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 
octave).
As I understand it, a propagated input means that X must always be installed 
with Y.

What benefit does this proposal bring us?

J'


-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net 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]