GNU make integration through an IDE
Bonjour Integrating make as the underlying engine ... is not easy 8-) For example to do a real Progress monitor, meaning how to provide feedback to the users on how many commands done so far and how many left ? How to extract information from make, i.e. make has all sort of information but the extracting is nearly impossible. Looking for ideas, or URL of projects that done this before. Finally, I hand up rewritting a Makefile Parser but ... why redoing make again and again. Lots of other tools been a spinnof Ant, jam etc ... because of this lacks of flexibility. P.S.: please CC not on the list. ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: GNU make integration through an IDE
%% "Alain Magloire" <[EMAIL PROTECTED]> writes: 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? 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. Also in the plans is integrating a true scripting language (Guile), which might make it easier for you to get what you need. -- --- 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
Re: GNU make integration through an IDE
> 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. ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: GNU make integration through an IDE
%% "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 t
