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

[John Darrington <john@darrington.wattle.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2518 bytes --]

On Sat, Jan 25, 2014 at 09:41:32PM +0100, Ludovic Court??s wrote:
     John Darrington <john@darrington.wattle.id.au> 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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]