Re: GNU make integration through an IDE

[Paul D. Smith]

%% "Alain Magloire" <address@hidden> writes:

  >> where do you go when the user asks to go to "install"?

  am> Ho! I do not know.  But it should not matter, we parse the
  am> makefile and provide the users with a list of the targets.  In
  am> your example should not the "install" targets be consider as the
  am> same one ...

  am> in theory, this is equivalent

  am> install: foo bar baz biz boz

  am> no ?

Yes, not only in theory but in fact.

But what I'm saying is that if you're providing a capability to jump to
where a target is defined, you'll have to pick one of those.  How do you
choose which one?  Or do you list the install target 3 times?

  am> Ok, I could use the "make -p" for validation.  For some reason
  am> I thought that the "-p" was just dumping the internal database not
  am> parsing the makefile also.

Well, it's hard to dump the internal database unless you've read the
makefile and constructed it first! :).

  >> Of course, the IDE can pre-set the locale to "C" before it invokes
  >> make when it's running it just to get information, like with -p or
  >> -n or whatever.

  am> Yes, but the output is also shown on some Widget console log.  If
  am> the user set the command to be "LANG=fr make", I (the user) will
  am> not be happy about the IDE interference.

My point was that if you have to do some kind of "preprocessing" like
invoke "make -p -n" to get build info _anyway_, then you might as well
set LANG=C for that invocation, which only the IDE cares about and the
user doesn't need to see.

Of course when you invoke the "real" build, without -p -n, then you
would use whatever LANG, etc. value the user provided.

  am> Does make have a consistent format when printing the errors,

Yes.

  am> let me give you a scenario:

  am> # cat Makefile
  am> all:
  am>   ./maain
  am> # make
  am> ./maain
  am> make: ./maain: Command not found
  am> make: *** [all] Error 127

  am> What I really want is the "Command not found"
  am> Why "Command not found" not part of "make: *** ..." error message.

This is different: these are not make errors!  These are errors in the
command script.  There's no way you can know what the format of the
error output for the command script will be, or even where it will
appear (stdout/stderr).

The last line, with the "***", is a make error line.  The syntax of the
make error message format is described in the GNU make manual section
that describes the error messages.

In this case, the command script failed and the failure code was 127, so
this line:

  make: *** [all] Error 127

says that the command script for the "all" target failed with error code
127.

  am> Basically, I'm just trying to find a way to provide meaningfull
  am> error markers to the user, so they will not have to dig through
  am> the gibberish of the build output log.

You want to look for the ": ***" token; those are errors generated by
make.  Again, see the GNU make manual.

  >> Now you run "make -n" without + support and what you get is:
  >> 
  >> cd sub1 && make
  >> cd sub2 && make
  >> cd sub3 && make
  >> cd sub4 && make
  >> cd sub5 && make
  >> 
  >> Only 5 commands, because make isn't recursing to the subdirectories.

  am> Understood, but this is good enough for me 8-).

Hm.  OK, well, maybe I don't understand what you're looking for then.
Note that of the 5 directories the first one might have 3 files that
could be built, the second one 3,000, the third 50, etc. so any progress
meter that simply relied on those 5 directories without knowing what's
in them wouldn't be very accurate.

  am> Well this is what we do now:
  am> we manage the makefile for them, basically we impose the structure.
  am> And the Makefile is not round-trip, meaning the "managedBuilder"
  am> overwrite the makefile everytime.

Ah!  So, it's very like VC++ project files or something.

Well, that's one way to do it, and if you do this then certainly most of
the advanced features we've been discussing are things you won't have to
worry about: since you're writing the makefile it's doubtful you'd
include those things (they are hard to automate).

  am> But in the future, with 
  am> - a smarter "make" error parser
  am> - some basic progress feedback done with "make -n"
  am> - Some good makefile editing capability
  am> - Some Makefile syntax validation
  am> - management of the makefile structure, for example,
  am>   it is conceivable to control things like Makefile.am.
  am>   Automake has a very strict structure that can be automate ... well
  am>   up to a point for the more complexe cases, we'll have to see.

  am> Would these approaches be better in your view ?

I think it's up to you.

As a _user_ I know what I would want though: I would want two modes.
One that wrote makefiles for me using whatever method you come up with:
directly, through automake, whatever.  As long as it was drop-dead
simple to use and accurate; in this mode I'd probably never care to even
see the makefile.

The other mode would be a "passthrough" mode which let me write my own
set of makefiles; here I'd want as much of the "helper" infrastructure
as practical including the editor help, the markup of make output to
find errors, etc. etc. BUT! in no way should that mode constrain what I
put into my makefile.  In that mode every decision of the IDE should be
"lenient"; it should not force me to do anything.  If the IDE doesn't
recognize what I'm doing it should shrug and just do its best to
interpret it, but let me do it.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist