RE: UPDATE: grep problem

[MCVEIGH Mark J <Mark dot Mcveigh at framatome-anp dot com>]

Dave,

As to the documentation in the INSTALL directory, You are correct.  My
failure was to read just the first line of README in that directory.  It
states, "This directory has been obsoleted for GCC snapshots and CVS
access." and being in a hurry to build, closed it and moved on.  --- Lessons
Learned ---.

Mark

-----Original Message-----
From: Dave Korn [mailto:dk@artimi.com] 
Sent: Friday, November 05, 2004 10:02 AM
To: 'MCVEIGH Mark J'; tmoore@redwood.rsc.raytheon.com;
ebotcazou@libertysurf.fr; tromey@redhat.com
Cc: gcc@gcc.gnu.org; 'WELLS AL'
Subject: RE: UPDATE: grep problem


> -----Original Message-----
> From: MCVEIGH Mark J
> Sent: 05 November 2004 16:54

> Dave,
> 
> Yes, I knew before this exploit that we didn't have the
> latest GNU make.
> Your note is interesting in that while you may be using the 
> latest make,
> your comment about my showing you a new feature means you might be
> referencing "*six* year old" make documents ;)  

  Nope, my make documents are up to date, but if you don't know a feature
exists, you don't tend to stumble across it, and since I haven't read every
single page but only referred to them as I needed.... well, you can see why
I hadn't heard of it before.

> I would expect any make would fail in a situation like this.
> The "call
> function " used in the GCC 3.4.2 makefiles is something like 
> 
> "$(call arg,arg,..)
> 
> As in all the make functions (shell, dir, call, etc.) there is at 
> least one space character differentiating them from a make macro.

  Alas, that turns out to be a false assumption.  Make macro variables are
not like shell variables; they are allowed to contain a much wider range of
characters, and in particular, spaces _are_ permitted.  Check this if you
want your mind to boggle:

-------------------------<snip!>-------------------------
dk@mace /test/make-tests> cat -n Makebar
     1
     2  This is a variable with spaces in it= Hello world!
     3
     4
     5  $(warning $(This is a variable with spaces in it))
     6  $(so this is just the name of an empty variable that expands to
nothing.)
     7
     8  all:
     9          echo The var is "$(This is a variable with spaces in it)"
    10
dk@mace /test/make-tests> make -f Makebar
Makebar:5: Hello world!
echo The var is "Hello world!"
The var is Hello world!
dk@mace /test/make-tests>
-------------------------<snip!>-------------------------

  This is in fact even documented: see
http://www.gnu.org/software/make/manual/html_chapter/make_6.html#SEC65

-------------------------<snip!>-------------------------
A variable name may be any sequence of characters not containing `:', `#',
`=', or leading or trailing whitespace. However, variable names containing
characters other than letters, numbers, and underscores should be avoided,
as they may be given special meanings in the future, and with some shells
they cannot be passed through the environment to a sub-make (see section
Communicating Variables to a Sub-make). 
-------------------------<snip!>-------------------------

  Interestingly enough, it is possible to use them on the command line in
bash as I did in the example above, but my guess is that make did the
substitution itself and passed the fully expanded result to the shell.

>  I would think that
> any GNU make version would look through it's list of make functions, 
> determine this was an unknown and flag it by output of some message. 
> Instead, the old make just ignored the problem.  No output whatsoever 
> to indicate the attempted "call" function didn't work.  I'd like
> to think the
> newer make adds more checking of each feature used but probably not.

  I had a long discussion with the make maintainer, a very patient and
helpful chap called Paul Smith, over on the cygwin list.  See
http://www.cygwin.com/ml/cygwin/2004-04/msg00777.html
and references and followups, or google at
http://www.google.com/search?q=Cygwin+make+thinks+a+statement+can+be+neither
+sit
e:cygwin.com&hl=en&lr=&filter=0

  We went into some depth about these kind of accidental features of make,
and how the very very simple (and somewhat ambiguous) syntax of make
requires a very simple parser which can easily be lead astray.  However, he
did point out that there's an option that in fact _will_ catch these sorts
of errors for you: since the command is being taken as an expansion of an
empty (in fact undefined) variable, there's an option to warn about such
variables if they are ever
referenced:

-------------------------<snip!>-------------------------
dk@mace /test/make-tests> make -f Makebar --warn-undefined-variables
Makebar:5: Hello world!
Makebar:6: warning: undefined variable `so this is just the name of an empty
var iable that expands to nothing.' echo The var is "Hello world!" The var
is Hello world! dk@mace /test/make-tests>
-------------------------<snip!>-------------------------

> It would be nice if the GCC doc files indicated such things
> as GNU make release level requirement right up front.  

  Yes, I agree that could only help.

>  Everybody probably reads the base directory files, NEWS,
> ChangeLog, etc.  For GCC 3.4.2, only file, NEWS, says
> GNU make is required and no version indicated.  I did find 
> reference to requiring GNU make 3.79 or later in file 
> gcc/doc/install.texi but it seems
> rather hidden and I don't build the info files before 
> building the code.  

  So, you only read the NEWS and ChangeLog?  If you only read the files in
the base dir, you won't find out how to configure, build or install gcc at
all, since there aren't any build instructions in the top level at all.

  There is, however, a rather prominent directory named INSTALL.  It
contains the output files built from the info.  It even contains a file
called README which has the words "[...]the installation documentation is
generated from gcc/doc/install.texi and copied into this directory" in it!

  However, as you have observed, there's no specific version requirements
listed.

> It just makes sense to have a build requirements doc in the base
> directory.

  I don't think that's so important: anybody who isn't going to read the
stuff in INSTALL is going to come a cropper anyway.  But I do agree the
requirements should be listed clearly.
  
> Anyway my problem is fixed and hopefully yours as well.

  Yep, thanks.

> Gentlemen, have a good day.... It's FRIDAY !

  Hallelujah!  Have a great weekend!

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....