Re: GNU make integration through an IDE

[Paul D. Smith]

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

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

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

  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.

  am> duplicate targets,

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

  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.

  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.

  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?

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

  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.

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

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.


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.

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