%% "Alain Magloire" <[EMAIL PROTECTED]> writes: >> where do you go when the user asks to go to "install"?
am> Ho! I do not know. But it should not matter, we parse the am> makefile and provide the users with a list of the targets. In am> your example should not the "install" targets be consider as the am> same one ... am> in theory, this is equivalent am> install: foo bar baz biz boz am> no ? Yes, not only in theory but in fact. But what I'm saying is that if you're providing a capability to jump to where a target is defined, you'll have to pick one of those. How do you choose which one? Or do you list the install target 3 times? am> Ok, I could use the "make -p" for validation. For some reason am> I thought that the "-p" was just dumping the internal database not am> parsing the makefile also. Well, it's hard to dump the internal database unless you've read the makefile and constructed it first! :). >> 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> Yes, but the output is also shown on some Widget console log. If am> the user set the command to be "LANG=fr make", I (the user) will am> not be happy about the IDE interference. My point was that if you have to do some kind of "preprocessing" like invoke "make -p -n" to get build info _anyway_, then you might as well set LANG=C for that invocation, which only the IDE cares about and the user doesn't need to see. Of course when you invoke the "real" build, without -p -n, then you would use whatever LANG, etc. value the user provided. am> Does make have a consistent format when printing the errors, Yes. am> let me give you a scenario: am> # cat Makefile am> all: am> ./maain am> # make am> ./maain am> make: ./maain: Command not found am> make: *** [all] Error 127 am> What I really want is the "Command not found" am> Why "Command not found" not part of "make: *** ..." error message. This is different: these are not make errors! These are errors in the command script. There's no way you can know what the format of the error output for the command script will be, or even where it will appear (stdout/stderr). The last line, with the "***", is a make error line. The syntax of the make error message format is described in the GNU make manual section that describes the error messages. In this case, the command script failed and the failure code was 127, so this line: make: *** [all] Error 127 says that the command script for the "all" target failed with error code 127. am> Basically, I'm just trying to find a way to provide meaningfull am> error markers to the user, so they will not have to dig through am> the gibberish of the build output log. You want to look for the ": ***" token; those are errors generated by make. Again, see the GNU make manual. >> 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. am> Understood, but this is good enough for me 8-). Hm. OK, well, maybe I don't understand what you're looking for then. Note that of the 5 directories the first one might have 3 files that could be built, the second one 3,000, the third 50, etc. so any progress meter that simply relied on those 5 directories without knowing what's in them wouldn't be very accurate. am> Well this is what we do now: am> we manage the makefile for them, basically we impose the structure. am> And the Makefile is not round-trip, meaning the "managedBuilder" am> overwrite the makefile everytime. Ah! So, it's very like VC++ project files or something. Well, that's one way to do it, and if you do this then certainly most of the advanced features we've been discussing are things you won't have to worry about: since you're writing the makefile it's doubtful you'd include those things (they are hard to automate). am> But in the future, with am> - a smarter "make" error parser am> - some basic progress feedback done with "make -n" am> - Some good makefile editing capability am> - Some Makefile syntax validation am> - management of the makefile structure, for example, am> it is conceivable to control things like Makefile.am. am> Automake has a very strict structure that can be automate ... well am> up to a point for the more complexe cases, we'll have to see. am> Would these approaches be better in your view ? I think it's up to you. As a _user_ I know what I would want though: I would want two modes. One that wrote makefiles for me using whatever method you come up with: directly, through automake, whatever. As long as it was drop-dead simple to use and accurate; in this mode I'd probably never care to even see the makefile. The other mode would be a "passthrough" mode which let me write my own set of makefiles; here I'd want as much of the "helper" infrastructure as practical including the editor help, the markup of make output to find errors, etc. etc. BUT! in no way should that mode constrain what I put into my makefile. In that mode every decision of the IDE should be "lenient"; it should not force me to do anything. If the IDE doesn't recognize what I'm doing it should shrug and just do its best to interpret it, but let me do it. -- ------------------------------------------------------------------------------- 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
