Re: GNU make integration through an IDE

[Alain Magloire]

> 
>   am> It looks like a Class View, the widget is a tree, that shows the
>   am> directives of the makefile, it turns out to be practical, for
>   am> makefile browsing etc ..  select a node it position the editor
>   am> cursor at the right place, future could do some quick action, like
>   am> shows the immediate available rule for the IDE build, "all",
>   am> "clean", "install-dist", etc ..
> 
> OK.  This level of parsing is not difficult, or you could use -p
> output.
> 
> Of course, it's complicated by the fact that you can have things like:
> 
>   install: foo bar baz
> 
>     ...
> 
>   install: biz
> 
>     ...
> 
>   install: boz
> 
> where do you go when the user asks to go to "install"?
> 

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

in theory, this is equivalent

install: foo bar baz biz boz

no ?


>   >> I don't know what you mean by this: GNU make reads all the
>   >> makefiles in and will report all syntax errors before it runs any
>   >> rules at all.  It does not invoke rules _as_ it is reading the
>   >> makefiles (that could never work because variables could be reset
>   >> at any time).  I don't see how it could report syntax errors any
>   >> faster.
> 
>   am> It is one more weapon in the arsenal.  For now syntax errors in
>   am> the build is detected late, meaning that it will be detected when
>   am> you will start the build(way to late).  If we are able to run make
>   am> as validator to check Makefiles syntax errors, certainly could be
>   am> a bonus.
> 
> I don't understand why you say it can't be detected until you start the
> build.  It can.  Any invocation of make, with any set of flags including
> things like -p or -n or even just -q, will immediately report any syntax
> errors.
> 
> How would adding an extra flag that did the same thing help?
> 

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

Thanks for clearing this up.

I'll give a try see how much it scales.

>   am> Of course, some errors will not be seen, for example a command
>   am> that copy a file with incorrect permissions etc ...  But things
>   am> like bad condition syntax,
> 
> This will be caught during any invocation of make, even one that doesn't
> build anything.
> 

OK.

>   am> duplicate targets,
> 
> You mean, with where both have command scripts right?  This is also
> warned about during any invocation of make.
> 

Noted.

>   am> a command directive missing the leading <TAB>,
> 
> If this leads to a syntax error, then this will also be caught during
> any invocation of make.
> 

Noted.

>   am> - depending on the locale, the error may change.
> 
> 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.
> 

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

>   am> - change the error on different version and it will no longer match.
>   am> - how about on the next version of make you add a new error message?
>   am> - strncmp("No rule to make target", line, len)
> 
> Yes, these are good points.  I guess my concern would be that adding
> another number to the error output would confuse the user in some
> situations: is this a make error ID or an error number generated by the
> program that make invoked?

I was thinking of some options to tell make to prefix the output
with some error number, but ... it may not be such a good idea.

Does make have a consistent format when printing the errors, let me
give you a scenario:

=======================
# cat Makefile
all:
        ./maain
# make
./maain
make: ./maain: Command not found
make: *** [all] Error 127
=======================
What I really want is the "Command not found"
Why "Command not found" not part of "make: *** ..." error message.

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

And to do this I need some clear rules or format so I could
make some educated guess of what went wrong.

>   am> Agreed, but I do not want an accurate estimate, I want a rough
>   am> estimates on how many commands make will run. So I can monitor the
>   am> output and give some level of feedbacks to the user.
> 
> But what I'm saying is that you won't even get _close_ to rough
> estimates without this capability.
> 
> Take a common scenario for large programs: you have 5 top-level
> directories, and a simple makefile that invokes submakes in each one.
> Underneath each of these are complex directory structures with hundreds
> of source files building libraries, executables, documentation, etc.
> 
> 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.
> Not only that but you'll _ALWAYS_ get these same five commands, because
> make always recurses to those subdirectories (otherwise it might not
> build everything it needs to).
> 

Understood, but this is good enough for me 8-).
Ok, I see the point.  I'll give it a try with "make -n" and put a word
of warning to the users about the use of "+"

>   am> Unfortunately the "+" could be use in a manner that doing the dry
>   am> run could affect/disturb the next build.
> 
> Yes, but that's to be considered a bug in the makefile.
> 

8-)

>   >> foo.o: CFLAGS = -O2
>   >> bar.o: CFLAGS = -g
>   >> 
>   >> foo.o bar.o:
>   >> $(CC) $(CFLAGS) -o $@ -c $*.c
>   >> 
>   >> If you put your cursor over the $(CFLAGS) reference in the rule, what
>   >> will the IDE print as the value for that macro?
> 
>   am> Good point, I forgot the GNU Target specific variable extension.
> 
> Note that this is not a GNU-only feature: both Solaris make and BSD make
> also provide it although using different syntax.
> 

Ok, news to me.

> Also, you can get the same sorts of problems using standard POSIX make
> syntax, with no fanciness:
> 
>     foo.o_CFLAGS = -O2
>     bar.o_CFLAGS = -g
>     CFLAGS = address@hidden
> 
>     foo.o bar.o:
>         $(CC) $(CFLAGS) -o $@ -c $*.c
> 
>   am> You are saying there are no good ways to integrate make/makefile
>   am> support in an IDE.  I admit not the feedback hoping for 8-).
> 
> No, I think that's going too far.  Things which you have mentioned here,
> such as what Emacs makefile-mode does in terms of colorizing makefile
> syntax, things like using an index mode to jump around, even more
> advanced things like helping users find the matching ifdef for an endif,
> etc. are all very useful.
> 

Agreed.  Any other ideas to improve the Makefile support?

> 
> I am saying that I think an IDE can help people edit makefiles but I
> don't think that an IDE can build a good makefile _for_ you, so IDE
> features like putting down templates, etc. I just don't think are that
> useful.
> 

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

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

Would these approaches be better in your view ?