Re: GNU make integration through an IDE

[Paul D. Smith]

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

  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.

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.

  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> (1) && (2)
  am> I've dealt with those a little differently: by providing in the
  am> IDE a Makefile Editor that understands GNU peculiar(really
  am> peculiar/inconsistent 8-) syntax, it provides:

There's nothing about GNU make syntax that's more peculiar or
inconsistent than the syntax of any other make (IMO).

  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?

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.

  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.

  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.

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.

  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.

  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?

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


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.

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