Re: GNU make integration through an IDE
%% "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
Re: GNU make integration through an IDE
"Paul D. Smith" wrote: > 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? Not that I agree with creating an IDE, but how do IDE's typically do it for overloaded function names and re-used static linkage or anonymous namespace symbols? > 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. IMHO, this is another reason not to use recursive make. > 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). OTOH, developers who know make and want to take advantage of advanced features will be extremely limited and frustrated. I know I would be. For example, as I've said before, we have a standard infrastructure. But being an infrastructure, I'm free to use the parts I want, override the parts that don't fit, and add stuff I want. In my specific case, I was able to encode our package version dependencies and have them checked at build time (ie during make makefile parsing) such that conflicting versions will cause a build error. > 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. I just use "cp" on an existing 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. I completely agree. MTC, Noel -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: GNU make integration through an IDE
> First, thanks for taking the time to respond some of the inquiries. > >> 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? > The outliner shows all the targets as distinct. Meaning, the parser does do any rule/parsing/interpretation of what it finds, it just builds a syntax Tree, the user will see something like this: + Makefile | install | CFLAGS |---+ idef | |- install | |- CFLAGS | all | distclean The target dialog list(where a user choose targets) will get the syntax tree collapse directives(Target) of the same name and present to the user a filter list, the user will see in the dialog. Choose the default build Target: -- install -- all -- distclean > 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. > Ok. > 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. > Ok, how about this scenario : SHELL=notfound all: echo me would not you consider this as a make error, i.e. the exec()/spawn()/system()/.. will fails. > 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. > I understand where you coming from, I'm just saying, taking the old example: == make ./maain make: ./maain: Command not found make: *** [all] Error 127 == The line that relevant to the user is make: ./maain: Command not found But is is hard to find, since there is no real marker/format. but ... sigh ... you are right, I can see a few cases where this is not so simple I want to make it sound 8-). Thanks. > 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. > Yes, we do this already, the problem is the error is cryptic, and it is difficult for the parser to make an automate guess of what is important to show to the user: make: ./maain: Command not found and the relevance of it. Usually we show: *** [all] Error 127 But its not helpfull and they(users) have to go back to scan the log. > >> 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 i
Re: Static pattern usage
On Fri, Oct 03, 2003 at 11:01:02PM +0200, Sam Ravnborg wrote: > I'm having troubles using static patters. > See following example: > > deps_foo.o := foo.h > > foo.o : % : $(deps_%) bar.h FORCE > @echo $^ > > FORCE: > > > When executed I expected it to print: > foo.h bar.h FORCE > > But it only prints bar.h FORCE > > Is it coorect behaviour that make does not expand the variable > $(deps_foo.o)? > % is equal to foo.o in the above example, and the varibale is > constructed correct. But it is not expanded. Short question.. Is there any other way to get the name of the target to be used in the prerequisite list? Other make implementation expands $* to the name of the target when listed in the prerequisites, but not gnu make. Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Static pattern usage
I'm having troubles using static patters. See following example: deps_foo.o := foo.h foo.o : % : $(deps_%) bar.h FORCE @echo $^ FORCE: When executed I expected it to print: foo.h bar.h FORCE But it only prints bar.h FORCE Is it coorect behaviour that make does not expand the variable $(deps_foo.o)? % is equal to foo.o in the above example, and the varibale is constructed correct. But it is not expanded. GNU Make 3.80 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Static pattern usage
%% Sam Ravnborg <[EMAIL PROTECTED]> writes: sr> deps_foo.o := foo.h sr> foo.o : % : $(deps_%) bar.h FORCE sr> @echo $^ sr> When executed I expected it to print: sr> foo.h bar.h FORCE sr> But it only prints bar.h FORCE Right. sr> Is it coorect behaviour that make does not expand the variable sr> $(deps_foo.o)? Yes, because that's not the variable you asked to expand. You asked it to expand the variable $(deps_%). sr> % is equal to foo.o in the above example, No it isn't; or at least it isn't when the prerequisites line is expanded. The entire target definition line, including the prerequisites, is expanded _BEFORE_ the line is parsed. When expansion happens the pattern substitution hasn't occurred yet, so you're expanding a variable named "deps_%" which doesn't exist, and so it expands to nothing. See the GNU make manual for a precise description of when expansion happens in various constructs. -- --- 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: Static pattern usage
%% Sam Ravnborg <[EMAIL PROTECTED]> writes: sr> Is there any other way to get the name of the target sr> to be used in the prerequisite list? sr> Other make implementation expands $* to the name of sr> the target when listed in the prerequisites, but not gnu make. No make expands $* in the prerequisites list to the name of the target. Some makes support a feature where $$@ (note two $'s!) in the prerequisites list will expand to the name of the target. GNU make also supports this syntax (see the GNU make manual). However, this won't help you because again, the $$@ is not expanded until _after_ all the other variables are expanded. This is true even for other versions of make which support this syntax. The only way to do what you want is to use the $(eval ...) function to declare extra dependencies. Something like: OBJS = foo.o deps_foo.o := foo.h $(foreach target,$(OBJS),$(eval $(target): $$(deps_$(target (note, this is untested). -- --- 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: Static pattern usage
On Fri, Oct 03, 2003 at 05:26:54PM -0400, Paul D. Smith wrote: > > No make expands $* in the prerequisites list to the name of the target. Hmmm.. foo.o : _$* FORCE echo $^ FORCE: I expected make to print out: make: *** No rule to make target `_foo.o', needed by `foo.o'. Stop. But I got: make: *** No rule to make target `_', needed by `foo.o'. Stop. That seems to me that make does not expand $* to the target. See also the manual: Section: Missing: * In some Unix `make's, the automatic variable `$*' appearing in the prerequisites of a rule has the amazingly strange "feature" of expanding to the full name of the _target of that rule_. We cannot imagine what went on in the minds of Unix `make' developers to do this; it is utterly inconsistent with the normal definition of `$*'. And it does not seem to happen in the above example. > The only way to do what you want is to use the $(eval ...) function to > declare extra dependencies. Something like: > > OBJS = foo.o > deps_foo.o := foo.h > > $(foreach target,$(OBJS),$(eval $(target): $$(deps_$(target Not an option for me - I have to support 3.79.1. Thanks for feedback. Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Static pattern usage
On Fri, Oct 03, 2003 at 05:18:04PM -0400, Paul D. Smith wrote: > > sr> Is it coorect behaviour that make does not expand the variable > sr> $(deps_foo.o)? > > Yes, because that's not the variable you asked to expand. You asked it > to expand the variable $(deps_%). Got it now, found the right section in the manual. IMMEDIATE :-( I will go back and invent another way to do what I want. Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Static pattern usage
%% Sam Ravnborg <[EMAIL PROTECTED]> writes: sr> On Fri, Oct 03, 2003 at 05:26:54PM -0400, Paul D. Smith wrote: >> No make expands $* in the prerequisites list to the name of the target. sr> Hmmm.. sr> foo.o : _$* FORCE sr> echo $^ sr> FORCE: sr> I expected make to print out: sr> make: *** No rule to make target `_foo.o', needed by `foo.o'. Stop. sr> But I got: sr> make: *** No rule to make target `_', needed by `foo.o'. Stop. sr> That seems to me that make does not expand $* to the target. Yes, that's what I said. No make expands this way. Or using other words, "no version of make exists that expands this way". If I had wanted to write that make _did_ do this, I would have added a comma or semicolon. This would mean "you're incorrect, make does expand $* ...": No, make expands $* ... while this means "no version of make expands $* ...": No make expands $* ... sr> Not an option for me - I have to support 3.79.1. Then your only way is to use the auto-re-exec trick. -- --- 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
