%% "Alain Magloire" <[EMAIL PROTECTED]> 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 = [EMAIL PROTECTED] 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 <[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