Re: GNU make integration through an IDE

[Alain Magloire]

> 

First, thanks for taking the time to respond some of the inquiries.

>   >> 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?
> 

The outliner shows all the targets as distinct.
Meaning, the parser does do any rule/parsing/interpretation of what it
finds, it just builds a syntax Tree, the user will see something like this:

+ Makefile
|---- install
|---- CFLAGS
|---+ idef
|   |----- install
|   |----- CFLAGS
|---- all
|---- distclean

The target dialog list(where a user choose targets) will get the syntax tree
collapse directives(Target) of the same name and present to the user
a filter list, the user will see in the dialog.

Choose the default build Target:
-- install
-- all
-- distclean

>   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.
> 

Ok.

>   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.
> 

Ok, how about this scenario :

SHELL=notfound
all:
        echo me

would not you consider this as a make error, i.e. the 
exec()/spawn()/system()/..  will fails.

> 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.
> 

I understand where you coming from, I'm just saying, taking the old example:
==================
make
./maain
make: ./maain: Command not found
make: *** [all] Error 127
==================

The line that relevant to the user is
        make: ./maain: Command not found
But is is hard to find, since there is no real marker/format.

but ... sigh ... you are right, I can see a few cases where this is not so 
simple
I want to make it sound 8-).

Thanks.

>   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.
> 

Yes, we do this already, the problem is the error is cryptic, and
it is difficult for the parser to make an automate guess of
what is important to show to the user:
        make: ./maain: Command not found
and the relevance of it.

Usually we show:
        *** [all] Error 127

But its not helpfull and they(users) have to go back to scan the log.


>   >> 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.
> 

FYI, we did the experience here, two cases:

- Placebo: we simulate a progress monitor: something like say we start
  at 100 ticks, each line we see going by increment the tick counter,
  then we recalibrate when reach a certain threshold ...
  simple and effective, the users have the impression of things "building".

- We do this correctly, spawning "make -n" get the log detect in
  the log lines and increment.

Suprisingly ... they(users) did not see a difference
And some without knowing felt the placebo version was more accurate !!  ...sigh 
..
At least for smaller project.

>   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).
> 

8-) Tell you the truth, we could go all the way, meaning generate
the Makefile at the last second(Just before the build) and remove it after.
Since all the information is kept internally.  We just use GNU make because
it is an excellent builder and do the job well.
But then again ... Some folks __need__ to have control.

>   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.
> 

Yes ... We will look at it.
Playing with make is actually an interesting exercice.
It is not that GNU make or the "make way" is not good or difficult
it's the way too approach the problem.

Thanks a million for the feedback.