Re: GNU make integration through an IDE

[Alain Magloire]

> 
>   am> Let's start with a few:
> 
>   am> 1) Error Parsing.
> 
> What about it?
> 
>   am> 2) Makefile editing/parsing.
> 
> Why is editing makefiles something that GNU make needs to handle?  There
> are things like Emacs makefile mode, for example, that already do a very
> nice job of this.
> 

Emacs is at the top of food chain 8-).
The point was early error discovery of errors,
it could make the developement cycle faster.

> Parsing I can see, vaguely, but I think you can get most of what you
> need, in a practical sense, from the -p output.  Nevertheless a
> "makefile elaborator" would probably help you somewhat here as well.
> However, you have to realize that you can't actually know what the value
> of variables, etc. will be until the makefile is actually run, and that
> the value of a given variable could well be quite different in different
> targets.

Agreed.

>   am> 3) Real feedback progress
> 
> This is simply not something make can do, at least not without
> significant architectural changes that I don't believe are worthwhile to
> the majority of people.  The way it can be done now (using -n first) is
> the best compromise I believe.
> 

...

>   am> - outliner
> 
> Don't know what this means: how can you outline a makefile?  Makefiles
> have no scope, there is no blocks, no nested/nestable areas... there are
> just variables and rules, all at the same level.  What does the outline
> consist of?
> 

It looks like a Class View, the widget is a tree, that shows the directives
of the makefile, it turns out to be practical, for makefile browsing etc ..
select a node it position the editor cursor at the right place, future
could do some quick action, like shows the immediate available rule
for the IDE build, "all", "clean", "install-dist", etc ..

> I guess you could hide/display the command scripts for rules or maybe
> the value of variables (if they're long), but that level of parsing is
> quite trivial; those syntax rules are very easy to follow and don't
> require an entire makefile parser.
> 

Yes, we are going down that path, did not finish the exploration,
some nice additions can still be done, to help the user.

>   am> - error detections
>   am> - quick fix(the infamous, TAB versus spaces), future work.
>   am> - content assist
>   am> - hovering to resolve macros
> 
> See below.  I doubt that at least the last two can realistically be
> done, unless you restrict yourself to only very simple makefiles.
> 
>   am> It could be interresting to have in GNU make a:
> 
>   am> make --verify -f Makefile
> 
>   am> Why wait to the last minute to discover some syntax errors when it
>   am> could be discover before.
> 
> 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.
> 

It is one more weapon in the arsenal.  For now syntax errors in
the build is detected late, meaning that it will be detected when
you will start the build(way to late).  If we are able to run make as validator
to check Makefiles syntax errors, certainly could be a bonus.
Of course, some errors will not be seen, for example a command
that copy a file with incorrect permissions etc ...
But things like bad condition syntax, duplicate targets,
a command directive missing the leading <TAB>, etc ...

>   am> For now we provided a GNUMakefileSyntaxValidator, to catch errors
>   am> quickly and not let the user lost in sea of make output logs, when
>   am> things go wrong.  Meaning for me, this is clear:
> 
>   am> # make[2]: *** no target for all
> 
>   am> But it is suprising to see how much users are intimidated by this.
> 
> First, that's not an error message make ever prints.  It will print:
> 
>     No rule to make target 'all'
> 
> Second, that's not a syntax error.
> 

Ok, my mistake.

> I suppose it would be handy to some people if the IDE had a popup to
> give more details about various types of error messages, but I don't see
> what this has to do with GNU make; it's not appropriate for GNU make to
> print an explanatory paragraph for each error it generates.
> 
> Finally on this topic, GNU make already has rigorous and carefully
> followed rules for the syntax of generated error and warning messages
> which should make them quite trivial for the IDE to watch for and mark
> in the output.  So, I'm really no clear on what changes you would like
> to see to GNU make in this area.
> 

- depending on the locale, the error may change.
- change the error on different version and it will no longer match.
- how about on the next version of make you add a new error message?
- strncmp("No rule to make target", line, len)
  Is this is the best way to look for errors/warnings or any relevant 
information
  that make wants to convey.

There was a proposition for gcc to also output numbers, so an IDE
could look at its catalog.


>   am> get the pre-output do the reall "make" and search for clues in the
>   am> passing logs to see where we at.  But it turns out that the dry
>   am> run is not really dry, since you could circumvent this by
>   am> prepending a "+" in front of the command.
> 
>   am> How about:
> 
>   am> # make --force-dry-run
> 
>   am> which really __only__ prints out the list of commands
> 
> This doesn't make any sense.  The point of "+" is to tell make that even
> when you're not running commands you still want to run this one, because
> without it you won't see all the proper commands.  It's used to invoke
> recursive makes: without this your top level makefile would run and
> print:
> 
>     cd subdir && make
> 
> or whatever, but it wouldn't _RUN_ that submake so who knows how much
> work would be done there?  If you're trying to get an accurate estimate
> of how much work make will do, then you definitely can't afford to
> disable "+" during -n processing.
> 

Agreed, but I do not want an accurate estimate, I want a rough estimates
on how many commands make will run. So I can monitor the output and
give some level of feedbacks to the user.
Unfortunately the "+" could be use in a manner that doing the
dry run could affect/disturb the next build.

>   am> Could we do something like:
> 
>   am> # make --elaborate-macro  CFLAGS
>   am> # make --expand-macro  CFLAGS
> 
> I don't think this is useful, in many ways.  First, it would be very
> slow to invoke make and have it parse all the makefiles, etc. just to
> print one variable value.
> 
> Second, as I mentioned above the real value of any given variable cannot
> really be determined outside of a target context, because any given
> target could have a different value for that variable.  Consider this:
> 
>   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?
> 

Good point, I forgot the GNU Target specific variable extension.

>   >> Also in the plans is integrating a true scripting language (Guile),
>   >> which might make it easier for you to get what you need.
> 
>   am> Do not see, how it will benefit an IDE written in java, at firts
>   am> glance.
> 
> The idea is that the scripting language has some access into make's
> internal structures, so in theory you could use it to get more
> information out of make and display it in whatever form you wanted,
> etc.
> 

Yes, this is one reason why a tool like Ant, is getting more popular.
make seems to be a "black box", not easy to extended or integrate with it.

> 
> However, let's take a step back.
> 
> To my mind IDEs for makefiles are not really practical in the first
> place.  Things like a "makefile mode" that do colorizing of text and
> help with things like TAB vs. spaces, etc. is great and very useful.
> But wholesale IDEs that try to help you write makefiles by templating,
> etc. to my mind lead people the wrong way.
> 
> If you look at a tool like VC++ and their "project" files you'll see
> what I mean: the "makefiles" generated by these tools are not good
> makefiles.  Tools like this basically resort to the least common
> denominator which is writing individual rules for every target, etc.  A
> good makefile consists of a few variable settings, maybe a pattern rule
> or two, and some dependency statements and that's it!  There's no way
> that an IDE can write that kind of abstraction for you properly.
> 
> 
> It's important to not think of makefiles like programs: they're not
> programs.  Trying to write an IDE that uses paradigms taken from
> languages like C and Java might do OK for simple "stupid" makefiles, but
> it won't work well with "real" makefiles.
> 

Fair enough.

You are saying there are no good ways to integrate make/makefile support in an 
IDE.
I admit not the feedback hoping for 8-).

Could GNU make go in a direction, for the future, that will make integration 
possible ?
What are the alternatives ? turn to other tools(like ANT, etc ...) ? reinvent
yet another IDE specific build mechanism ?

Most C/C++ IDE when it comes to good integration to a builder simply drop make
and use some other formats.

I am just looking for feedbacks on how to tackle the issue, maybe the answer
is not to change make and build other tools around it that can exploit its
build paradigm?
The goals are simple, help the users in the development cycle.