Re: GNU make integration through an IDE

[Alain Magloire]

>   am> For example to do a real Progress monitor, meaning how to provide
>   am> feedback to the users on how many commands done so far and how
>   am> many left ?
> 
> First, make can't tell you how many commands are left because it doesn't
> know.  This came up a few weeks ago.  The way make works is it starts at
> the first node in the dependency graph and works along until it's done.
> Make never knows how many operations are left to do, so it never knows
> when it will be finished until it already is.
> 
> Second, how would you envision the communication between make and the
> IDE during the build in the first place?  I can't think of any generic
> way to do it other than having the IDE watch the output.  Any sort of
> out-of-band communication seems very non-portable and specific to me.
> 
>   am> How to extract information from make, i.e. make has all sort of
>   am> information but the extracting is nearly impossible.
> 
> Well, what are you looking for?
> 

Let's start with a few:

1) Error Parsing.
2) Makefile editing/parsing.
3) Real feedback progress

(1) && (2)
I've dealt with those a little differently: by providing in the IDE
a Makefile Editor that understands GNU peculiar(really peculiar/inconsistent 8-)
syntax, it provides:
- outliner
- error detections
- quick fix(the infamous, TAB versus spaces), future work.
- content assist
- hovering to resolve macros

It could be interresting to have in GNU make a:

make --verify -f Makefile

Why wait to the last minute to discover some syntax errors when it could be 
discover before.
For now we provided a GNUMakefileSyntaxValidator, to catch errors quickly and 
not let the
user lost in sea of make output logs, when things go wrong.  Meaning for me, 
this is clear:

# make[2]: *** no target for all

But it is suprising to see how much users are intimidated by this.


(3) was much harder
Try to emulate by doing a dry run

# make --dry-run

get the pre-output do the reall "make" and search for clues in the passing logs
to see where we at.
But it turns out that the dry run is not really dry, since you could
circumvent this by prepending a "+" in front of the command.

How about:

# make --force-dry-run

which really __only__ prints out the list of commands

>   am> Finally, I hand up rewritting a Makefile Parser but ... why
>   am> redoing make again and again.  Lots of other tools been a spinnof
>   am> Ant, jam etc ... because of this lacks of flexibility.
> 
> I definitely want to have a flag that displays an "elaborated" makefile;
> say with all immediate variables expanded, etc.  This is especially
> important now that we have $(eval ...) because that can be hard to debug
> without this.
> 

Could we do something like:

# make --elaborate-macro  CFLAGS
# make --expand-macro  CFLAGS

I suppose, I could do programaticallly something equivalent:

# make -p | grep -w ^CFLAGS


> Also in the plans is integrating a true scripting language (Guile),
> which might make it easier for you to get what you need.
> 

Do not see, how it will benefit an IDE written in java, at firts glance.

Again, I do not have yet a clear understanding of all the issues.
Maybe the answer is not to change "make" but build better tools
around it to take full advantage of it.
This is why I ask for feedbacks.