> > 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"? >
Ho! I do not know. But it should not matter, we parse the makefile and provide the users with a list of the targets. In your example should not the "install" targets be consider as the same one ... in theory, this is equivalent install: foo bar baz biz boz no ? > >> 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? > Ok, I could use the "make -p" for validation. For some reason I thought that the "-p" was just dumping the internal database not parsing the makefile also. Thanks for clearing this up. I'll give a try see how much it scales. > 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. > OK. > am> duplicate targets, > > You mean, with where both have command scripts right? This is also > warned about during any invocation of make. > Noted. > 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. > Noted. > 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. > Yes, but the output is also shown on some Widget console log. If the user set the command to be "LANG=fr make", I (the user) will not be happy about the IDE interference. > 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? I was thinking of some options to tell make to prefix the output with some error number, but ... it may not be such a good idea. Does make have a consistent format when printing the errors, let me give you a scenario: ======================= # cat Makefile all: ./maain # make ./maain make: ./maain: Command not found make: *** [all] Error 127 ======================= What I really want is the "Command not found" Why "Command not found" not part of "make: *** ..." error message. Basically, I'm just trying to find a way to provide meaningfull error markers to the user, so they will not have to dig through the gibberish of the build output log. And to do this I need some clear rules or format so I could make some educated guess of what went wrong. > 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). > Understood, but this is good enough for me 8-). Ok, I see the point. I'll give it a try with "make -n" and put a word of warning to the users about the use of "+" > 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. > 8-) > >> 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. > Ok, news to me. > 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. > Agreed. Any other ideas to improve the Makefile support? > > 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. > Well this is what we do now: we manage the makefile for them, basically we impose the structure. And the Makefile is not round-trip, meaning the "managedBuilder" overwrite the makefile everytime. But in the future, with - a smarter "make" error parser - some basic progress feedback done with "make -n" - Some good makefile editing capability - Some Makefile syntax validation - management of the makefile structure, for example, it is conceivable to control things like Makefile.am. Automake has a very strict structure that can be automate ... well up to a point for the more complexe cases, we'll have to see. Would these approaches be better in your view ? _______________________________________________ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make