[bug #38433] Example for eval in documentation contains error with define
Follow-up Comment #2, bug #38433 (project make): Paul and Philipp, Daniel has a valid point here. You could be a lot more welcoming on this case, why so hard on him? I hit the very same thing myself some time ago, just forgot to speak up myself. That documentation bug is the reason meta programming in GNU make took my too starts, rather than one. While I appreciate progress in GNU make, version 3.82 has produced costs over 3.81 to many parities, see the list of bugs related to 3.82-caused breakage in Gentoo Linux alone: https://bugs.gentoo.org/show_bug.cgi?id=331977. To summarize: people need all the support with the transition and with understanding the differences betwen 3.81 and 3.82 they can get. Daniel could have prepared a patch for the docs by now and be motivated to do more later, if you had instructed him about it. The good part about it: you may have a second chance. Don't let it pass. Best, Sebastian ___ Reply to this item at: http://savannah.gnu.org/bugs/?38433 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: prerequisites alter choice of pattern match rules?
On 25.02.2013 14:57, Brian J. Murrell wrote: Hi, I have run into something I find strange with GNU Make 3.81 (yes, I know 3.82 is latest but since it's not in EL6, my target platform, I cannot depend on it's features). I would think that given the following set of rules: /tmp/%.foo: %.foo echo foo rule 1 touch $@ %.foo: echo foo rule 2 touch $@ /tmp/%.bar: make $*.bar echo bar rule 1 touch $@ %.bar: echo bar rule 2 touch $@ [..] $ make /tmp/a.foo echo foo rule 2 foo rule 2 touch /tmp/a.foo $ make /tmp/a.bar make a.bar make[1]: Entering directory `/home/brian/chroma/deps/lustre/test' echo bar rule 2 bar rule 2 touch a.bar make[1]: Leaving directory `/home/brian/chroma/deps/lustre/test' echo bar rule 1 bar rule 1 touch /tmp/a.bar It would seem that for the /tmp/a.foo, the /tmp/%.foo pattern rule is not being chosen but for /tmp/a.bar the /tmp/%.bar pattern rule is being chosen. The only difference in those choices I can see is that the /tmp/%.foo pattern rule has a prerequisite and the /tmp/%.bar one doesn't. Confirming the same behavior for make 3.82. It seems like normally GNU make walks the path of the most specific match in case of ambiguities. I wonder if that's specified/documented anywhere. For this Makefile xxx%: @echo '$@ -- xxx%' x%: @echo '$@ -- x%' xx%: @echo '$@ -- xx%' the most specific rule is chosen one might expect: # make x1 xx2 xxx3 4 x1 -- x% xx2 -- xx% xxx3 -- xxx% 4 -- xxx% Side notes on the above Makefile: - make $*.bar in there does not seem to be relevant. After removing that line, the file still reproduces your case. - make $*.bar should be $(MAKE) $*.bar, use $(MAKE) to invoke make to not run into parallel build issues - To reduce output noise, you can use lines like @echo foo rule 1 ^ instead of echo foo rule 1 So the question is, why does a prerequisite change the behavior of pattern match rules? Good question. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Infinite loop bug with parallel make
On 22.02.2013 03:31, Ian Lynagh wrote: Hi all, The attached Makefile causes an infinite loop with parallel make when using make 3.81 (on amd64/Linux): $ make setup touch B.hs A.hs sleep 2 touch B.hi B.dyn_hi sleep 2 touch B.o B.dyn_o sleep 2 touch A.dyn_hi sleep 2 touch A.o A.dyn_o $ make so true 1 B.hi B.o false 1 make: *** [so] Error 1 $ make so -j2 true 1 B.hi B.o [doesn't terminate] I was able to reproduce that behavior GNU Make version 3.81-r2 found in Gentoo Linux. When I turn the last call into $ make so -j2 --debug it keeps looping File `so' does not exist. I can't reproduce it with 3.82, but I don't know for sure whether it's fixed or whether it's just luck that it doesn't get tickled. However, even if it is fixed in 3.82, that doesn't really help me right now as I would really like my build system to work with the make that people have installed, and 3.81 is still very common. I cannot reproduce it with 3.82, either. Is anyone able to explain what causes the bug, so that I can try to alter the build system to avoid it, please? My understanding is that the trouble comes from rules that * are not declared phony but still * do not update the timestamps of their targets . A solution could be to a) Add a line .PHONY: so A.dyn_o A.hi Aa.o B.hi A.hs so that all deep dependencies of target so .. so A.dyn_o A.hi Aa.o B.hi A.hs .. are marked phony or b) add lines tabtouch $@ to all pattern rules and a new rule to update A.o A.o: tabtouch $@ to make sure timestamps are updated as expected. With either approach, the looping stops with 3.81-r2 for me. I do not mean to say that the unmodified Makefile GNU make should loop, I am not sure about that. However, the Makefile does have its part. As a last resort (meaning if you cannot do changes like those mentioned above to your Makefile for sonme reason), you could make the Makefile require GNU make 3.82 or later: minimum_version := 3.82 recent_enough := $(filter $(minimum_version),$(firstword \ $(sort $(MAKE_VERSION) $(minimum_version ifeq ($(recent_enough),) $(error GNU Make $(minimum_version) or later is minimum_versioned) endif That's an adapted version of an idea from http://www.jgc.org/blog/cookbook-sample.pdf. Also, is there a way to tell make not to treat any file as intermediate? I think that it's possible that this would work around the problem. If that's not possible, then if I can make a list of all files that the build system might build then adding list of all files : | exists exists: touch $@ would do it, right? Although then, if the build system didn't actually find a rule for a file in the list, then the dependency on exists would make it think that it could build it; is there any way to avoid that? I do not understand that part, sorry. Please elaborate more. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: failure anoucement during installation of cinelerra-4.4
Hello Karl-Heinrich, to me it looks like you are having trouble compiling Cinelerra 4.4. This mailing list is dedicated to issues with GNU make itself. You might want to write to help-m...@gnu.org, instead, see Mailing Lists on [1]. Also, please make sure to share English program output rather than German one. Running LC_ALL=en_US make rather than make might do the trick, but I cannot properly test that at the moment. Best, Sebastian [1] https://www.gnu.org/software/make/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: failure anoucement during installation of cinelerra-4.4
Hello Karl-Heinrich, to me it looks like you are having trouble compiling Cinelerra 4.4. This mailing list is dedicated to issues with GNU make itself. You might want to write to help-m...@gnu.org, instead, see Mailing Lists on [1]. Also, please make sure to share English program output rather than German one. Running LC_ALL=en_US make rather than make might do the trick, but I cannot properly test that at the moment. Best, Sebastian [1] https://www.gnu.org/software/make/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: feature request - order only deps
On 03.02.2013 23:20, Matěj Týč wrote:
If that happens how about replacing
$(MAKE) cache-foo
by something like
mkdir .lock 2/dev/null || exit 0 ; \
$(MAKE) cache-foo ; \
ret=$$?; \
rmdir .lock exit $${ret}
The idea is:
- mkdir can only succeed once
- if $(MAKE) cache-foo fails
1. the whole should return non-zero
2. .lock is not left laying around
Thank you,
but just by looking at it, I think that if .lock exists, 0 is returned
and while one make job is busy loading the cache, the others act like
the cache was loaded.
Writing the makefile and trying it confirms this assumption, so I guess
that it has to behave like that.
I see, so actually waiting is needed.
Have you tried modifying the call to do that? I'd bet it's possible :-)
I am beginning to think that the most elegant (from the user's point of
view) would be (probably optional) ignore of order-only dependencies if
the target exists and is more up-to-date than its ordinary dependencies.
To my understanding, it would have to be optional and off by default to
not break other cases that are currently supported. Think of something like
tmp:
mkdir tmp
tmp/foo.pdf: foo.tex | tmp
pdflatex -output-directory tmp $
In this scenario, the tmp directory needs to be created if missing.
How difficult could be writing a patch that would enable this?
No idea without having a closer look. To be honest, I am not yet
convinced that this feature would be of real use to other users or that
a new a global switch would be the best way to address this issue, if
really wanted.
Best,
Sebastian
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Re: feature request - order only deps
On 04.02.2013 00:13, Matěj Týč wrote: On Ne, 2013-02-03 at 23:40 +0100, Sebastian Pipping wrote: To my understanding, it would have to be optional and off by default to not break other cases that are currently supported. Think of something like tmp: mkdir tmp tmp/foo.pdf: foo.tex | tmp pdflatex -output-directory tmp $ In this scenario, the tmp directory needs to be created if missing. Actually this would not be a problem, I would need to ignore the 'tmp' target iff 'tmp/foo.pdf' existed and was more up-to-date than 'foo.tex'. So in cases like that the behavior even wouldn't change at all. I think that the problem could arise in cases like this: Dirs: dir1 dir2 dir%: mkdir $@ dir2/foo: dir1/bar touch $@ dir1/bar: | Dirs touch $@ .PHONY: Dirs If you make 'dir1/bar', then remove 'dir2' and decide to make 'dir2/foo', you appreciate that 'dir2' is remade because 'dirs' is an order-only dep of 'bar' and it is remade as soon as make realizes that 'dirs' is not complete because 'dir2' is missing. So although this can be considered as the Makefile bug, cases like this can exist, so the proposed change would break this behavior (I propose that the 'Dirs' order-only dep is ignored because dir1/bar is all right and dir2/foo says that it depends only on dir1/bar) If I am not mistaken, you are saying that: If 1. an order-only dependency is missing and 2. the target is not re-built (i.e. neither missing or older than normal prerequisites the order-only dependency should not be built. I'm starting to see why you want support for that. I think that this is a nice idea, since 'make' doesn't play well with filters that can process batches of files at once, the server process is a good way to reduce overhead of processing those files one by one and you may end up needing a cache quite soon :-) Actually I might be wrong, but I think that if I have a program 'filter' capable of processing in01 in02 in03 ... files to out01 out02 out03 ... etc., it is not possible to tell this to 'make', so if out05 and out07 are needed at some point, 'make' would call 'filter in05 in07 --some --flags'. Is that right? Because if this was somehow possible, I would not need that process at all. I do not see the relation to the rest of this thread yet, but what you describe sounds like classic pattern rules: out%: in% cp $ $@ Here, cp would be the filter. Are you referring to something else? Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: feature request - order only deps
On 02.02.2013 16:19, Matěj Týč wrote: This is what I understand to be our current Makefile: bar_deps = foo1 foo2 bar: $(bar_deps) $(bar_deps): | cache-foo %: touch $@ [..] Thank you for your quick help, your example indeed works, but it has one weakness. Consider a case when eg. 'foo1' depends on 'baz' and suddenly 'baz' is updated, so 'foo1' should be updated, too. However, the old 'foo1' is still there, so the 'file_missing' function assumes that nothing has to be done = cache-foo is not needed, which is not true. Since I generate the makefile using some M4sugar macros, I don't mind having to write some extra stuff; however now the workaround path seems to complicate quite a lot... How about something like this? bar_deps = foo1 foo2 bar: $(bar_deps) $(bar_deps): $(MAKE) cache-foo touch $@ %: touch $@ Now cache-foo is remade iff at least one of $(bar_deps) needs a rebuild. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: feature request - order only deps
On 02.02.2013 18:38, Matěj Týč wrote:
How about something like this?
bar_deps = foo1 foo2
bar: $(bar_deps)
$(bar_deps):
$(MAKE) cache-foo
touch $@
%:
touch $@
I have also thought of that, but this can work well reliably only in the
case if there is only one make job. If I specify -j4, it may happen that
all jobs will attempt to load the same cache simultaneously, which I
have to avoid :-(
If that happens how about replacing
$(MAKE) cache-foo
by something like
mkdir .lock 2/dev/null || exit 0 ; \
$(MAKE) cache-foo ; \
ret=$$?; \
rmdir .lock exit $${ret}
The idea is:
- mkdir can only succeed once
- if $(MAKE) cache-foo fails
1. the whole should return non-zero
2. .lock is not left laying around
If that works for you conceptually, you could abstract a little more and
turn it into something re-usable like
$(call synced_make,cache-foo)
Best,
Sebastian
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Re: feature request - order only deps
On 01.02.2013 16:18, Matěj Týč wrote: Hi, I have noticed that if we have a target that has prerequisities, if those prerequisities are missing and I want to make the target, then even if the target file exists, prerequisities are remade if possible and then, consequently, the target has to be remade, too, since its prerequisity is now more up-to-date. Which, of course, makes perfect sense. However, if a prerequisity is order-only, it is also going to be remade despite the target file existis already, but unlike the case above, the target won't be remade because it is allowed to be older than its order-only prerequisity. This is normally not an issue, since order-only prereqs are probably often cheap commands lke mkdir etc., but my case is different: Consider a server process that can execute commands and that can load (huge) data into cache to spped the execution up. Loading the data is a make task and a target file cache-foo is created to expose that the data has been succesfully loaded into the server cache. Then cache-foo is an order-only dependency of foo1, foo2 and foo3 targets that take advantage of it (rules to make them call the server process that uses the foo cache). Therefore those targets are not made before setting the cache up and also the cache is loaded once, not concurently even if like -j4 is used as a make argument. As you might guess, if I have a target 'bar' that depends on 'foo1' and 'foo2', then even if 'foo1' and 'foo2' exist, if 'cache-foo' is missing, it is remade and data are loaded into the cache without being of any use, which is quite annoying. In other words, the whole server might have to start, load the cache and then do nothing. This is what I understand to be our current Makefile: bar_deps = foo1 foo2 bar: $(bar_deps) $(bar_deps): | cache-foo %: touch $@ Now you want that cache-foo is not built if all of $(bar_deps) exist. We can achieve that by only adding cache-foo as a dependency, if former is not the case. So let's replace the line $(bar_deps): | cache-foo by $(bar_deps): | $(if $(call any_file_missing,$(bar_deps)),cache-foo,) using two custom functions: # $(call file_missing,file_1) # returns: # true (actually $(file_1)) if the file is missing # false (empty string) if the file exists define file_missing $(if $(wildcard $1),,$1) endef # $(call any_file_missing,file_1 file_2 ..) # returns: # true (a non-empty string) if any file is missing # false (empty string) if all file exist define any_file_missing $(strip $(foreach filename,$(1),$(call file_missing,$(filename endef I hereby put that into the public domain. This session confirms it working: $ touch foo1 foo2 bar $ make make: `bar' is up to date.# cache-foo not built! $ rm foo1 $ make touch cache-foo # cache-foo built, since foo1 is missing touch foo1 touch bar I'm curious, if that helps. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: not linking
Hello Jack, On 22.12.2012 15:20, Jack Riegel wrote: I created a 2-line fortran program and a simple make file (below) to illustrate the problem that I am having. When I run make, I get the following output. Note that if I simply copy and paste the final gfortran line (the linking step) into my terminal window, the executable builds. It is as if make is overriding the normal library location. I have not tried specifying a library location, but it does not seem that it should be necessary. seems to work well over here. Are you using a version of GCC that does not come with your GNU/Linux distribution? # make gfortran -c makeTest.f90 gfortran makeTest.o -o makeTest.x # ./makeTest.x hello # which gfortran /usr/bin/gfortran # gcc -dumpversion 4.5.4 # make -v | head -n 1 GNU Make 3.82 # uname -m x86_64 Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: bug!!! error2!!!
Hello, please try to use a more to the point mail subject line next time. Especially !!! should be avoided: it cuts down the number of people willing to even read the mail body by a half easily. I doubt that's in your interest :-) Thanks. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Contact Paul D. Smith
Hello Eric, On 10/13/2012 05:09 PM, Eric Seerden wrote: Hi all, I'm trying to get in contact with Paul D. Smith who worked with rms on the GNU make (gmake) utility apparently he is now the maintainer of the software.. Many thanx in advance for your help.. Since you have the attention of a whole mailing list now (rather than just Paul) please explain what your plans/problems with GNU make are (if it's not super secret). That would give the rest of the list a chance to see if it's something that really you need exactly Paul for, which I guess maybe you don't. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: root/test make problem
On 06/19/2012 10:19 PM, igle...@unifesp.br wrote: Dear Sirs, I am tryinng to install root (cern) in ubuntu 12.04 in order to run a R package called xps. I could install root following many posts advices (I am not an expert on linux) and the tutorials run fine. However, I can not install the test directoty with make. I got this: Generating dictionary EventDict.cxx... rootcint -f EventDict.cxx -c Event.h EventLinkDef.h make: rootcint: Command not found First, please note that this is _not the right place_ for your question. The xps or root communities are probably the ones to contact. From a technical point of view: Somewhere in the makefile a call to rootcint is made. You can probably find that spot with # fgrep -Ri rootcint . Either you have command rootcint somewhere an need to fix the makefile so it can be found. Or you do not have rootcint at all. In that case, that needs fixing first. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: compile error
Hello, On 05/05/2012 11:24 PM, Le Gluon du Net wrote: Bonjour, j'aimerai compiler le snapshot de raine sous Ubuntu 12.04 mais j'ai une erreur: $ make Building Raine, Fully optimized version with gcc for linux-gnu CPU=pentium-m dependencies : if you get an error here, install the required dev package libpng:1.2.46 SDL:1.2.14 Compiling source/z80/mz80help.c... source/z80/mz80help.c:35:75: erreur fatale: version.h : Aucun fichier ou dossier de ce type compilation terminée. make: *** [linux-gnu-sdl/object/z80/mz80help.o] Erreur 1 merci pour votre aide. this list is about trouble with GNU make itself. Your problem seems to be about compilation of raine [1], not about GNU make. PS: if you don't understand french, tell me, I will return you this mail in english. Better try the other way around next time. If a mailing list is not explicitly language X it's English only in most cases. Best, Sebastian [1] http://rainemu.swishparty.co.uk/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 02/28/2012 08:12 PM, Sebastian Pipping wrote: Without looking any closer than your email I may prefer to handle this through the maintainer build step, rather than committing gnulib files directly to the make source control. But I'll have to investigate. I'm aware this can be done off- or in-repository. I chose the in-repository approach because that makes future updates visible in version control history. If you prefer the other approach, I'm still fine. In that case, adding autogen.sh or a boostrap script would be nice to add. Any news on thw how of gnulib? Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
make manual: CFLAGS and linking
Hello, on page [1] it reads: CFLAGS should be used in every invocation of the C compiler, both those which do compilation and those which do linking. It would be nice to have an explanation why CFLAGS whould be used with linking, too. Maybe with an example or a dedicated section in the manual. Thanks, Sebastian [1] https://www.gnu.org/prep/standards/html_node/Command-Variables.html#Command-Variables ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 02/28/2012 05:37 PM, Paul Smith wrote: On Mon, 2012-02-27 at 17:39 +0100, Sebastian Pipping wrote: If been playing with gnulib integration by now: Thanks Sebastian. I'll take a look at this but probably not until the weekend. I was on vacation (scuba diving from a live-aboard off Belize--and yes it was exactly as fantastic as it sounds, if not more!) all last week and now I'm swamped at work. Sounds like fun. Without looking any closer than your email I may prefer to handle this through the maintainer build step, rather than committing gnulib files directly to the make source control. But I'll have to investigate. I'm aware this can be done off- or in-repository. I chose the in-repository approach because that makes future updates visible in version control history. If you prefer the other approach, I'm still fine. In that case, adding autogen.sh or a boostrap script would be nice to add. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 02/13/2012 05:41 PM, Paul Smith wrote: Pulling in an implementation from gnulib, just in case, might be the way to go. This seems to be the entry point: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=modules/vasnprintf I'd make a new directory gnulib and copy needed files in. How should integration work on build system level? Is this stuff you want to play with for yourself or would you rather have me try X Y for you? What would X Y be? Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 02/12/2012 05:27 PM, Eli Zaretskii wrote: Date: Sun, 12 Feb 2012 05:07:48 +0100 From: Sebastian Pipping sebast...@pipping.org CC: psm...@gnu.org, bug-make@gnu.org So far both of these have been requirements: (1) keep the overall format translatable so other languages can adjust order of elements and (2) use C89 functions, only. It seems that (1) requires function vsnprintf which violates (2). Why does (1) violate (2)? (1) will only be possible with C libraries that support the n$ positional specifiers. AFAIK, when these are supported, they can be used with any of the *printf functions. The problem is nesting. If we have _(%s[%u]: %s%s%s%s) ^^ for the final output, the actual message (third %s above) needs to be present in linear string form already. With constant messages that's given, but we are dealing with _(%s: Entering directory `%s'\n) too. So that inner format needs to be written to a string buffer first or we lose the gained abstraction. Since we would run into buffer overflows with sprintf/vsprintf, we rely on snprintf/vsnprintf for that task. Quoting from my man 3 printf output: snprintf(), vsnprintf(): _BSD_SOURCE || _XOPEN_SOURCE = 500 || _ISOC99_SOURCE \ || _POSIX_C_SOURCE = 200112L; or cc -std=c99 That's my understanding of the situation. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
Hello again, with v5 [1] of the color patch we have moved into a situation where a choice needs to be made: - either we require/bundle/re-write CRT function vsnprintf or - we sacrifice the ability to translate the order of message components (i.e. _(%s:%lu: %s%s%s%s) and two friends) Please let me know how to proceed. Best, Sebastian [1] http://hartwork.org/public/make-CVS-color-v5.patch ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 02/12/2012 05:03 AM, Eli Zaretskii wrote: Date: Sun, 12 Feb 2012 02:04:47 +0100 From: Sebastian Pipping sebast...@pipping.org Cc: bug-make@gnu.org with v5 [1] of the color patch we have moved into a situation where a choice needs to be made: - either we require/bundle/re-write CRT function vsnprintf or - we sacrifice the ability to translate the order of message components (i.e. _(%s:%lu: %s%s%s%s) and two friends) Please let me know how to proceed. What exactly is the problem you are trying to solve? (Apologies if this was already written somewhere.) So far both of these have been requirements: (1) keep the overall format translatable so other languages can adjust order of elements and (2) use C89 functions, only. It seems that (1) requires function vsnprintf which violates (2). That's we need to make a choice. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Cleanup of makefiles 'n stuff
On 01/17/2012 06:28 AM, Eli Zaretskii wrote: For sure once I actually take the plunge and move to a real source code control system [...] May I suggest bzr? It is a GNU project and is used by Emacs, wget, and a few others on Savannah. Git please. It's fast, used by important GNU projects [1] and a ton of others, and I sure don't want to miss Git's staging/index mechanism. I can help with the conversion, if you want help with it. Best, Sebastian [1] http://git.savannah.gnu.org/cgit/coreutils.git ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
Hello, great to hear from you. On 01/04/2012 02:06 AM, Paul Smith wrote: On Sun, 2012-01-01 at 01:31 +0100, Sebastian Pipping wrote: I have to say that I feel that David's point of 20 Oct is well-taken, that a more flexible command line interface would be better. Alright. I propose to transform --output-format=(color|plain) into --format=(plain|colorized) . What do you want the parameter to look like? I'm not sure what you mean by the parameter? Sorry. I was referring to all of --format=(plain|colorized) not just the (plain|colorized) part. The above looks OK to me although I prefer color (and allowing colour for our non-U.S. English speakers). Good. As for the code, I have a concern about the way strings are being constructed. One of the hardest parts about generating output in a GNU program is the requirement to support i18n. GNU make is not perfect but it is making strides and I think the new behavior actually moves us a step backwards. I'm thinking in particular of the PREFIX capabilities. The problem is that not all languages are read left-to-right: some are read right-to-left. So, if you create output strings with prefixes that are generated first and not part of the translated string, then those prefixes cannot be swapped for languages that are read right-to-left: they always come on the left, when they should come on the right. Some of the output we generate, such as the error() function, already has this problem. But in other areas we avoid it by constructing the string completely including the prefix, and translating that. I confess I'm not an expert in i18n, so it's quite possible I'm making something out of nothing very important here. But I think it's worth investigating. It's possible, for example, that it's sufficient to translate the prefix string itself if everything is printed in one invocation. I see. I'm all for a proper solution to that. With output like make[4]: foo failed pushing full control into translation strings seems troublesome to me. Imagine %s[%u]: foo failed %s[%u]: bar failed ... in the translation database. It doesn't get much better with make[%u]: foo failed make[%u]: bar failed ... What do you think about specify a reading direction for each supported language and making use that information to select from prefix or suffix? With that information pure translation strings foo failed bar failed can be turned into either make[4]: foo failed make[4]: bar failed or foo failed: make[4] bar failed: make[4] or even foo failed: [4]make bar failed: [4]make on the fly. If translation allows strings only we could let people translate READING_DIRECTION to LEFT_TO_RIGHT or RIGHT_TO_LEFT and assume left-to-right unless we get a match for RIGHT_TO_LEFT. What do you think? Beyond that, I'm not excited about having to add a parameter specifying whether there's a newline or not. I'm assuming that if you don't switch back the color to the default before the \n is printed, you get ugly output, is that it? I'd actually prefer the output.c code to be a little more complex and check to see if the string ends in a newline and handle that internally, rather than have all the callers have to pass a special flag specifying newlines. I can implement that and resolve the flag, no problem. Ditto for the flush() call. I'm not sure why we'd ever want to NOT flush, and I'm not sure why there's an explicit flush() some places but not others. Alright, let it always flush. If we do end up needing extra flags, I wonder if there's some way to combine them with the message type to avoid needing an extra parameter. As you wish. Also please don't worry about updating copyright years: I have a utility that does that automatically for all the files at once. Noted. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
Hello again, I have integrated your review into a new version of the color patch. Version 4 is up at http://hartwork.org/public/make-CVS-color-v4.patch . There are the changes since the last version: # git log --oneline | tac | tail -n 5 b9aaec5 Revert addition of 2011 to copyright years 35801fd Resolve OF_FLUSH and flush unconditionally 4120d5f Resolve flag OF_APPEND_NEWLINE, detect trailing newline 838bc37 Merge two enum parameters into a new one 932f2f6 Rename parameter --color[=(yes|no)] to --format=\ (plain|color|colour) For individual commits see http://git.goodpoint.de/?p=make.git;a=shortlog;h=refs/heads/color-v4 . Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 01/05/2012 09:20 PM, Paul Smith wrote: What I mean is, instead of voutputf() invoking multiple calls to fprintf(), we'd need to compute all the strings we needed then invoke a single fprintf() for each output style where the format string was translated, something like this: if (flocp flocp-filenm) fprintf (target, _(%s:%lu: %s%s), flocp-filenm, flocp-lineno, catchy, output); else if (makelevel == 0) fprintf (target, _(%s: %s%s), program, catchy, output); etc. Of course we'd need to use vsprintf() or something to turn the va_list into the output string. Now a translator can take that format string and convert it so that things are generated in a different order if necessary. Function vsnprintf could be used to fill variable output. Quoting the local printf(3) man page: [..] int vsnprintf(char *str, size_t size, const char *format, va_list ap); [..] Feature Test Macro Requirements for glibc (see feature_test_macros(7)): snprintf(), vsnprintf(): _BSD_SOURCE || _XOPEN_SOURCE = 500 || _ISOC99_SOURCE \ || _POSIX_C_SOURCE = 200112L; or cc -std=c99 Is use of that function acceptable? The other thing I wonder about is the hardcoding of ASCII colorized strings There have to be defaults somewhere in there. Or not? and the start/stop character strings (\033[...). Are there other methods of colorizing? As of now I don't know any other. Should we try to support them? Maybe it's not worthwhile to try to support generic methods when we have no idea if they're useful. We can always make changes needed to support them later. Thanks. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 01/05/2012 09:46 PM, Eli Zaretskii wrote: The easiest way of abstracting this is to have a function that turns on a given color, and another function that turns off a color and returns to the default color. (Color can actually be some other attribute, like bold or blinking.) There should be a way to do this separately for foreground and background colors. Is this about the extraction of two functions of three lines each or is it about more? Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
Updates as requested: # git log --oneline | tac | tail -n 2 8e3918a Move output.(c|h) code to output_ascii.(c|h), make output.(c|h) a null layer 00d24e4 Reduce to single translated call to fprintf, extract functions (start|stop)_color http://hartwork.org/public/make-CVS-color-v5.patch or http://git.goodpoint.de/?p=make.git;a=shortlog;h=refs/heads/color-v5 The new version uses vsnprintf for now. I propose to bundle code for that function for systems that do not have it to solve that problem. An alternative would be write a simple custom vsnprintf that supports the rather small subset used by GNU make. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 11/13/2011 05:21 PM, Paul Smith wrote: I'll look at your code today. Any news? I have to say that I feel that David's point of 20 Oct is well-taken, that a more flexible command line interface would be better. Alright. I propose to transform --output-format=(color|plain) into --format=(plain|colorized) . What do you want the parameter to look like? Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #34608] comparison of unsigned expression 0 is always false
Follow-up Comment #10, bug #34608 (project make): Very nice, thanks! ___ Reply to this item at: http://savannah.gnu.org/bugs/?34608 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #34806] target-specific variable with conditional assignment generates garbage
Follow-up Comment #2, bug #34806 (project make): Would it be easy to isolate the related patch for you? If so, distros could integrate that before 3.83 comes out. So if it's easy, please attach the patch applied. Thanks! ___ Reply to this item at: http://savannah.gnu.org/bugs/?34806 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #34608] comparison of unsigned expression 0 is always false
Follow-up Comment #2, bug #34608 (project make):
Thanks for these details. Let me propose
#define INTEGER_TYPE_SIGNED(t) !((t) -1 0)
for a warning-less replacement then. Like it?
Please re-open the bug for me, as I lack permissions to.
I used the program below with
# gcc -Wall -Wextra main.c ./a.out
as a test:
#include stdio.h
#define INTEGER_TYPE_SIGNED(t) !((t) -1 0)
int main() {
printf(signed %dn, INTEGER_TYPE_SIGNED(unsigned char));
printf(signed %dn, INTEGER_TYPE_SIGNED(signed char));
printf(signed %dn, INTEGER_TYPE_SIGNED(char));
return 0;
}
___
Reply to this item at:
http://savannah.gnu.org/bugs/?34608
___
Message sent via/by Savannah
http://savannah.gnu.org/
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
[bug #34530] make (ab)uses the ASCII grave accent (0x60) as a left single quotation mark
Follow-up Comment #3, bug #34530 (project make): If Markus is on a crusade for it, does that make him wrong? I thought we were on a joint crusade for free software with GNU make. Paul, are you sure such a change would even be hitting translators? Either `foo' has been translated to `foo' so we knew what to fix it to ourselves. Or it has been translated to a better suitable tick in which case we would only have to touch the translation source side on that case. Am I missing anything? ___ Reply to this item at: http://savannah.gnu.org/bugs/?34530 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #34608] comparison of unsigned expression 0 is always false
Follow-up Comment #4, bug #34608 (project make): Can you re-open the bug until you made a decision? ___ Reply to this item at: http://savannah.gnu.org/bugs/?34608 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #34530] make (ab)uses the ASCII grave accent (0x60) as a left single quotation mark
Follow-up Comment #5, bug #34530 (project make): I was assuming that the strings itself are they keys, already. Would technically be possible for us to fix the hashes on our end to save the translators the trouble but still fix the trouble? I'm unsure if bouncing this back up to GNU level is a step forward. It would need either someone to dictate the change, everyone to agree or majority votes for a topic that has chances to either cause flamewars or face broad ignorance. It could take ages and easily drift off to nowhere or worse. And suck energy and time better spent elsewhere. So my proposal is to make the switch at make level and let Markus do the patching for you if he can. In case he cannot, maybe I can, but that would be January 2012 or later. ___ Reply to this item at: http://savannah.gnu.org/bugs/?34530 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #34608] comparison of unsigned expression 0 is always false
Follow-up Comment #5, bug #34608 (project make): You mentioned !((t) -1 = 0) . I do not get any warnings when using that in the mentioned code sample compiled with -Wall -Wextra and GCC 4.4.5. What warnings do you get? ___ Reply to this item at: http://savannah.gnu.org/bugs/?34608 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #34608] comparison of unsigned expression 0 is always false
Follow-up Comment #7, bug #34608 (project make): Interesting. For you code (with unsigned int) I get the warning, too. For unsigned char, I don't. No warnings in either case for 0 (as opposed to = 0. ___ Reply to this item at: http://savannah.gnu.org/bugs/?34608 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
Hello, the copyright assignment form reached the FSF more than a week ago. Would be great to get some more review on my patch now. I don't mind if on-list, off-list, half-half... Paul? Thanks, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: 2 errors on make
On 11/07/2011 11:11 AM, andrec wrote: On win32 systems : # Thanks Blackthorne, for corrections on the *.c rule SRC = *.c CFLAGS = -Wall -shared -g GLUT_DIR = src/glut/glx $(GLUT_DIR)/$(SRC) : $(GLUT_DIR)/*.h glut32.dll : gcc $(CFLAGS) $(GLUT_DIR)/$(SRC) -o glut32.dll C:\source\Mesa-7.11 07-11-2011 9:56:19,54 make make: `src/glut/glx/capturexfont.c' is up to date. C:\source\Mesa-7.11 07-11-2011 10:00:16,79 make make: `src/glut/glx/capturexfont.c' is up to date. C:\source\Mesa-7.11 07-11-2011 10:03:52,15 make make: Nothing to be done for `src/glut/glx/capturexfont.c'. Three thoughts on this: - If glut32.dll is made from $(GLUT_DIR)/$(SRC) it should depend on that. I'm thinking of something like this: glut32.dll: $(GLUT_DIR)/$(SRC) $(GLUT_DIR)/*.h $(CC) $(CFLAGS) $(LDFLAGS) $(GLUT_DIR)/$(SRC) -o $@ - It seems the output you provided does not indicate errors but rather informational messages. This does not look like a bug in GNU make. If you meant to report a bug, please explain in more detail. - Quoting https://www.gnu.org/s/make/: There is a separate list for general user help and discussion, help-m...@gnu.org. If that's what you are looking for, you can subscribe to that list at https://lists.gnu.org/mailman/listinfo/help-make Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
Hello again, I've been doing more work on the patch. Version 3 is up at [1]. Since version 2 I have made these changes: - Fix: error() printed twice (first with color, then a second time without) - Add support for customizing colors through environment variable MAKE_COLORS - Add missing newline to end of debugging message - Turn misc messages green by default, was cyan before - Introduce flag for erase in line (similar to what grep has) (Eli's feedback is not integrated yet, because I am waiting for a second opinion before applying that.) With v3 [1] applied, you could try these commands to get a feeling for current defaults and MAKE_COLORS: # make # ./make --color # export MAKE_COLORS='enter=0;42:leave=0;41:message=0:erase=yes' # ./make --color Best, Sebastian [1] http://hartwork.org/public/make-CVS-color-v3.patch ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 10/20/2011 06:40 AM, Paul Smith wrote: However it can take a bit to complete esp. if you reside outside the U.S. (inside the U.S. we can now use scanned documents via email but outside the U.S. we still must rely on physical mail). Outside U.S., yes. I'll send you some options and you can choose which you prefer. Got your mail. Check the README.cvs file, for now: Thanks for that pointer - worked. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
Hello again!
I have some new code ready for you to tear apart, err review :-)
I have re-written the patch so that version 2 at [1] does the following:
- Add parameter --color[=(yes|no)] to enable/disable color
from the command line. Minimal man page entry added, too.
- Integrate colorization into
- internal functions
- message()
- error()
- fatal()
- echo of commands being executed
- directory changes
- Integrate two new files output.h and output.c into
build system files.
The approach used is to have a general printing function that all output
passes through. A message type and a bunch of flags control details of
behavior, for instance if the output goes to stdout or stderr. This is
the current types and flags:
typedef enum _message_t {
OT_DIR_ENTER,
OT_DIR_LEAVE,
OT_MISC_MESSAGE,
OT_MISC_ERROR,
OT_MISC_FATAL,
OT_EXECUTION
} message_t;
enum {
OF_APPEND_NEWLINE = 0x1,
OF_PREPEND_PREFIX = 0x2,
OF_FLUSH = 0x4
};
Color codes are used _inside_ that function, only.
I'm looking forward to your feedback!
Best,
Sebastian
[1] http://hartwork.org/public/make-CVS-color-v2.patch
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
Hello David, to be honest I don't think that --output-format=color is a good choice with regard to usability (or the human factor). Also, it lacks the at-home-feeling for users of grep that --color provides. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 10/20/2011 08:43 PM, Eli Zaretskii wrote:
Date: Thu, 20 Oct 2011 20:19:33 +0200
From: Sebastian Pipping sebast...@pipping.org
I have some new code ready for you to tear apart, err review :-)
Here's mine:
Thanks Eli!
+ /* Determine target file (i.e. stdout or stderr) and color to pick */
+ switch (type)
+{
+ case OT_DIR_ENTER: target = stdout; color = color_dir_enter; break;
+ case OT_DIR_LEAVE: target = stdout; color = color_dir_leave; break;
+ case OT_MISC_MESSAGE: target = stdout; color = color_misc_message;
break;
+ case OT_MISC_ERROR: target = stderr; color = color_misc_error; break;
+ case OT_MISC_FATAL: target = stderr; color = color_misc_fatal; break;
+ case OT_EXECUTION: target = stdout; color = color_execution; break;
+ default: target = stdout; color = ; colorize = 0; break;
+}
This should probably be a data structure, indexed by the OT_* values.
Actually, I asked myself if I should go for a table lookup but I somehow
decided against it. (I was wondering if putting stderr into a stacic
map would end up with a fully initialized stderr or if there could be
races on that. If there can, I would need an extra function to get the
current value of stderr during runtime. I was also worried if C90 would
allow me to build that table as I wanted. That's where the doubts pot
flow over... an made me go to switch.)
So while I don't obect to such a change: what kind of gain are you
aiming here? Speed? Maintainability? Would be cool to hear more.
Best,
Sebastian
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 10/11/2011 10:11 PM, Sebastian Pipping wrote: Alright. Please initiate the copyright assignment process. Any news on this? So there are no preperations to do? I noticed that there is no bootstrap/autogen.sh script in CVS. What do I need to run to bootstrap GNU make? It seems that # autoreconf -i ./configure make leaves me with a repeated warning [..] configure.in:128: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body [..] from autoreconf and a File be.po does not exist error from make: [..] make[4]: Entering directory `/home/sping/__playground/make/po' File be.po does not exist. If you are a translator, you can create it through 'msginit'. make[4]: *** [be.po-create] Error 1 [..] Could you add a bootstrap/autogen.sh script to CVS? Any advice or progress here? Any more information you need from me? Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 10/12/2011 12:05 AM, Eli Zaretskii wrote: [..] To be truly portable, there should be an API that accepts a string and the information how to color it, and then a platform-specific backend actually produces the colored output and writes it to the screen. That's a good idea, actually. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
Hello! On 10/11/2011 07:51 PM, Paul Smith wrote: I have no problem with the concept of colorized output, as long as it meets the following requirements: * The default is no color mode as now Agreed. * The implementation is clean and portable and doesn't add lots of complexity to the code. Does everything support the color codes you're using? I don't want to have to link with ncurses or something to get portable colorization. No plans on using ncurses here. I suppose if we do what grep does were safe enough portability-wise? I'll check what I can learn from there. Regarding complexity it may (or may not) be necessary to split newlines off some translations strings and concat them at runtime, instead. It depends on the question if \n itself should be colorized or not. In general I don't expect much complexity. * The color designation is flexible: the last thing I want to do is get into a situation where we are scrambling to find acceptable colors for those who prefer terminals with light backgrounds, dark backgrounds, color blind folks, etc. Customizable, yes. I also don't want to have a new ~/.makerc file or something just to define color schemes. Okay. I guess that leaves command line options, environment variables or both. Any preferences? * Based on the above it seems like the code required to implement this will be sufficiently large that it will require copyright assignment to the FSF. Alright. Please initiate the copyright assignment process. * Patches based on the current CVS latest version of GNU make are easier for me to examine/apply/test. Sure. I will follow GNU make CVS in this new Git repo of mine [1]. I have ported patch v1 presented earlier to the current state in CVS. It's in branch color-v1.1 of [1], this URL [2] serves a raw patch. I noticed that there is no bootstrap/autogen.sh script in CVS. What do I need to run to bootstrap GNU make? It seems that # autoreconf -i ./configure make leaves me with a repeated warning [..] configure.in:128: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body [..] from autoreconf and a File be.po does not exist error from make: [..] make[4]: Entering directory `/home/sping/__playground/make/po' File be.po does not exist. If you are a translator, you can create it through 'msginit'. make[4]: *** [be.po-create] Error 1 [..] Could you add a bootstrap/autogen.sh script to CVS? Best, Sebastian [1] http://git.goodpoint.de/?p=make.git;a=summary [2] http://git.goodpoint.de/?p=make.git;a=patch;h=c901be5018830bbc5d9b2cac553fd4174189659b ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 10/03/2011 06:22 PM, Sebastian Pipping wrote: To re-summarize: - make does not color its output itself as of now - colorized output would help distincing output by make from output by programs involked by make, example at [1] - existing wrappers (like colormake [2]) have problems - There is a quickhack patch against make 3.82 at [3] - I am willing to keep working on that patch until you like it enough to apply it upstream - I don't know about your expectations on such a patch yet, but I need to know. Please get back to me on this. Thanks! Another week has passed by. Paul, can I have your opinion on this? Thanks! Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 10/03/2011 08:20 PM, David Boyce wrote: I have two reactions to the original post: 1. I hate colorized output in all its forms. If you want to add this feature and can get it in that's fine with me as long as it will never show up as a default in any native build of make. Off-by-default works for me. 2. I don't know if you've used Electric Make, which is a commercial make which aims for 100% GNU make compatibility, but they've extended their variant to allow for XML-tagged output. From this they can generate graphs and charts and derive metrics and so on. So I think a more general solution would be to offer XML-style output as a GNU make option, and then it would be trivial to post-process that for colorizing as well as a number of other useful purposes. I can think of a small list of make output categories. Let's see: recipe command lines printed by make verbosity other make output debug the stuff printed with -d dbthe stuff printed by make -p info text from the $(info) function error,warning as above ??? Anything not within one of the tags would be considered regular command output. If you were doing serial build, or parallel and had a synchronization feature such as in https://savannah.gnu.org/bugs/?33138, then output could be nested inside the recipe tag from which it derived which would be more useful. I'm pretty sure ecmake does something like that. Anyway, I think that would have more general utility than colorization per se. I see the versatility of that approach. I do not want to involve it with with colorization, though. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: some errors ,and I don't know the meaning
On 09/29/2011 08:57 AM, wu peter wrote:
Hello
I am Peter .I use make install,but there are some errors as
follow. Thanks for your answer.
Is it the problem that I am not the root.
for dir in libint libr12 libderiv; \
do \
(cd ${dir} make install) || exit 1; \
done
make[3]: Entering directory `/home/peter/libint-1.1.4/src/lib/libint'
/usr/bin/install -c -d -m 0755 /usr/local/libint/1.1.4-stable/include/libint
/usr/bin/install: cannot create directory `/usr/local/libint':
Permission denied
I suppose you get Permission denied because you need root permissions
to create directory /usr/local/libint, see here:
# ls -ald /usr/local/
drwxr-xr-x 9 root root 4096 Nov 11 2010 /usr/local/
So please try with sudo make install instead.
make[3]: *** [install_inc]Error 1
make[3]: Leaving directory `/home/peter/libint-1.1.4/src/lib/libint'
make[2]: *** [install]Error 1
make[2]: Leaving directory `/home/peter/libint-1.1.4/src/lib'
make[1]: *** [install] Error 1
make[1]: Leaving directory `/home/peter/libint-1.1.4/src'
make: *** [install]Error 1
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
[rfc] Colorized output for GNU make?
Hello! First, here's a picture of what this is about: [1]. Wrappers like colormake [2] have a number of problems: they cannot distinguish certain lines of output (like commands being executed and output produced by these very commands), they take more resources than needed just to name a few. So I was thinking: maybe you even want that feature upstream (or are at least willing to accept it) if it's done well? I volunteer to be the code monkey for that. I have a quickhack patch ready at [3] if you like to see it in action. I'm aware that you wouldn't apply that patch as-is. I came here to discuss what it should be transformed into. Related questions: - How should color be enabled/disabled? Would grep's approach of parameter --color[=(never|always|auto)] and variable GREP_COLORS be reasonable here? (Is there a need for --color=auto here?) Other ideas? - When colorizing abc\n, should color stop before or after \n? - The make code seems to support a variety of platforms. Which platforms should receive color, which shouldn't? Looking forward to hear from you! Best, Sebastian Pipping [1] http://hartwork.org/public/make-with-color.png [2] http://bre.klaki.net/programs/colormake/ [3] http://hartwork.org/public/make-3.82-color-v1.patch ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
