%% "Alain Magloire" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 _______________________________________________ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make