Re: [bug #40639] GNU Make with profiling information
Pe 11.01.2014 20:58, "Paul Smith" a scris: > > Sorry, I've been mostly away from my systems recently. > > > On Wed, 2013-12-18 at 13:28 +0200, Eddy Petrișor wrote: > > > Thanks for clarifying this. Could you please confirm if the general > > direction of the the is OK in the latest patch I sent? > > I will take a look. > > > What it is in scope and what I would need help with is adding relative > > time stamp support in the profiling info instead of absolute time > > stamps. When analyzing the 'simple' output I realised the graphs > > looked awful because there was such such a scale difference between > > the time stamp and duration. > > The absolute time stamp also doesn't fit well worth the scope of the > > 'simple' output. > > Does it have to be relative to the start of the entire build (user's > invocation of make)? Not necessarily. It can be relative to the first finished target or to some arbitrary start time. The idea is to easily analyse the extracted data without the need for extra effort. > > I understand the interest in the amount of time a given job takes to > run, but I guess I don't understand the need for a "start time offset" > at all. Isn't it sufficient to record the start time of a job, then > when it's complete show the elapsed time for that job? Or recipe? Or > both? The resulted information when using absolute time stamps is almost meaningless until they are further processed in an external tool because is hard to identify with a glance which job finished last, which first and so on. If a relative time stamp is provided one can waste less time on the analysis when some target is clearly the wasteful one. Also the relative time stamps generate very readable graphs directly after insertion in a tool such as Oocalc, Gnumeric or Excel. With absolute time stamps the very first thing I found myself doing was to generate relative time stamps. > > > I tried to pass down a reference time stamp through an environment > > variable, but I am missing something from the processing since > > submakes don't see the variable I defined. > > I'll take a look. > Sorry for not sending that. Since I had no feedback I wanted to avoid the confusion regarding which code to review. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Missing po files in GIT
On Tue, 2014-01-14 at 11:00 +0400, Pavel Fedin wrote: > Hello! > > I am trying to rebuild GIT version of Make, however .po files are missing > in the repository. Is this intentional ? I have copied them over from my > 4.0-2 archive. But where are they originally stored ? The PO files are dynamically downloaded from the translation site during builds when building from Git. This ensures we always have the latest versions. If you want to build from a Git checkout please be sure to read the README.git file. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: make doesn't complain if target cannot be built
-Philip Guenther schrieb: - >Betreff: Re: make doesn't complain if target cannot be built > In many cases, I've found it completely unnecessary to > list the source files. Just list the objects that should be built and > provide pattern rules for the source types, then let make figure out which > source files generate which objects from the patterns, ala: > > OBJS = foo.o bar.o ... > > %.o: %.c: > $(COMPILE.c) > > %.o: %.cpp > $(COMPILE.cpp) > > ... > > $(OBJS): generated.h > > You only need to match sources > to objects if there's a naming conflict...which I would tend to solve by > renaming the file that doesn't belong. This is the pattern I normally use. But as I described in my first mail, the line "$(OBJS): generated.h" does two things: 1. state that foo.o and bar.o depend an generated.h 2. state the foo.o and bar.o are target The second has the side effect, that make doesn't complain if foo.o cannot be generated because there no matching implicit rule. A "make foo.o" wouldn't complain and exit with 0 even if there's no foo.c. > Side point: you only list an > explicit dependency for a file named generated.h, which suggests you're using > some sort of automated dependency technique (gcc -MD, make depend, etc) for > handling dependency tracking for other .h files. Yes, I do. > If that's the case, then it can be slightly better to use an order-only > prerequisite for the generated file, ala: > $(OBJS): | generated.h > That guarantees the generated.h file will > exist before trying to build any objects, but if generated.h gets rebuilt, > only the objects that have real dependencies from the automated dependency > tracking setup will get rebuilt. That makes sense. > > Philip Guenther regards Christian -- Registergericht / Register Court: Amtsgericht Traunstein, HRA 460 / Local Court Traunstein, registered under HRA 460 vertreten durch / authorized representative: Anton Kathrein This e-mail is confidential and may contain privileged information. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. We believe but do not warrant that this e-mail and any attachments are virus free. You must therefore take full responsibility for virus checking. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #40639] GNU Make with profiling information
On Tue, 2014-01-14 at 11:58 +0200, Eddy Petrișor wrote: > > I understand the interest in the amount of time a given job takes to > > run, but I guess I don't understand the need for a "start time > offset" > > at all. Isn't it sufficient to record the start time of a job, then > > when it's complete show the elapsed time for that job? Or recipe? > Or > > both? > > The resulted information when using absolute time stamps is almost > meaningless until they are further processed in an external tool > because is hard to identify with a glance which job finished last, > which first and so on. > > If a relative time stamp is provided one can waste less time on the > analysis when some target is clearly the wasteful one. Also the > relative time stamps generate very readable graphs directly after > insertion in a tool such as Oocalc, Gnumeric or Excel. With absolute > time stamps the very first thing I found myself doing was to generate > relative time stamps. Sorry, I was not clear: I wasn't suggesting that it would be better to display the absolute time for the start time. I was wondering why we display the start time at all. Why not just show the elapsed time, and nothing else? That would avoid all of these issues. However Tim makes a reasonable point in his response so if it can be done without too much difficulty it would be good to show a relative start time. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: make doesn't complain if target cannot be built
On Tue, 2014-01-14 at 06:56 +0100, Christian Eggers wrote: > Am Montag, 13. Januar 2014, 17:20:43 schrieb Paul Smith: > > On Mon, 2014-01-13 at 22:23 +0100, Christian Eggers wrote: > > > In Makefile 2 my intention was to state that foo.o depends on some > > > generated header which must be generated first (might be in another > > > rule). But I didn't want to change the be behaviour if foo.o cannot be > > > built because e.g. there's no foo.c. > > > > Unfortunately, this behavior is correct, and even required by the POSIX > > standard (and is implemented by every version of make). > > Is there a workaround for this? Using explicit rules seems to be difficult in > my case because some objects are built from .c sources, other from .cpp. Can you add the prerequisite to the pattern rules? %.o : %.c generated.h $(COMPILE.c) ... %.o : %.cpp generated.h $(COMPILE.cpp) ... This has the definite potential downside that if "generated.h" changes then _every_ object file will rebuild, even if they do not use it. But maybe they all use it anyway. Alternatively you could use order-only prerequisites: %.o : %.c | generated.h $(COMPILE.c) ... %.o : %.cpp | generated.h $(COMPILE.cpp) ... Now you have the opposite problem: generated.h will be rebuilt BUT none the object files will be recompiled (if the only thing that's changed is the generated.h file). Really, I'm not sure I see the ultimate problem. First, it seems that you will always need to define header files, etc., so you will already have plenty of rules of the form: foo.o: bar.h biz.h and so this issue already exists. Second, if all you're worried about is someone adding a bogus file to the makefile list of objects, that doesn't seem like a real issue; sure, it won't be caught here but the build will still fail (presumably you're using that list of objects to construct something else and THAT will not work if one of the object files is missing). If you really want to catch it early you can just do a specific check to make sure all the listed files exist: SOURCES := foo.c foo.cpp foo.asm ... MISSING := $(filter-out $(wildcard $(SOURCES)),$(SOURCES)) ifneq (,$(MISSING)) $(error Missing files: $(MISSING)) endif It's definitely true that you won't be able to get the traditional make error message; I just don't think it's worth the hoops you'll need to jump through to make that happen. But maybe you have some other requirement. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #40639] GNU Make with profiling information
2014/1/12 Paul Smith : > On Wed, 2013-12-18 at 13:28 +0200, Eddy Petrișor wrote: >> Could you please confirm if the general direction of the the is OK in >> the latest patch I sent? > > Conceptually it seems OK. I'm still not jazzed about having any more > than one output format, and I'd prefer that format to be in a > more-or-less readable form, more like the "long" form than the others. If that will be the only format, then it would mean always imposing a lot more more work on the information processing stage due to necessary filtering and transformations to fit a format accepted or easily parsed in a tool such as Oocalc, Gnumeric or Excel. Although human readable seems nice and understandable, it is the least machine parseable, hence my choice for the 'simple' format to be default. > > I think the output should go in the standard make output format, so > something like: > > make[]: : > > Or, alternatively: > > []: > > Also I think it's enough to show the start offset and the elapsed time. > End offset is not necessary IMO. Unfortunately, depending on the used tools, when processing the information the end time is necessary. For instance, in Microsoft Excel the only way to display graphs for intervals is via a graph designed for visualising stocks' variation (and it even forces the insertion of an extra field). Oocalc is fine with start and stop, but for the graphs look awful and are unusable with absolute values (it scales so the entire 0-timestamp interval is visible, so a difference of a few seconds is invisible on the graph), so relative values are better here. OTOH, relative time stamps or just durations are useful for a human eye examination, since is easy to spot offenders that way. These are three different scenarios which I myself encountered and had in mind when designing the code the way I did. > > I'm unsure about the PID. This is the pid of the make process so I'm > not sure what the goal is. Is it to be able to collect all the times > together maybe? The goal is to be able to: - spot targets evaluated redundantly in a recursive makefile in different processes but on the same recursion level (these targets could be candidates to be moved in a parent make invocation) - spot wasteful/needless recursive calls (e.g. several targets called in different make processes when they could be grouped in a single call) - be able to analyse a single make invocation or a call sub-tree > > Is it necessary to dump all the output times at the end? Doing so > requires that we increase the size of the file structure to hold the > information, and this is already large AND the most common structure in > memory; there's one for every single target which for non-recursive > builds can get really big. I'm trying to keep memory usage under > control. > > If instead of that we print the information after each target is > complete we can shift the storage of this information out of the file > structure and into the commands structure or similar. To me it seems > more useful to keep the elapsed time info right next to the command > output rather than dumping it all at the end. I'm afraid I am missing some details of the implementation so I can't answer that question in any meaningful way. I will have to look into the code, but if a single target does NOT have multiple commands structures, it should work. Any pointers to the appropriate code area or suggestions would be welcome. > Some other comments: > 1. In general remember that GNU make code must conform to ANSI > C89 / ISO C90. We shouldn't be using newer features of the > language or runtime library unless we need to, and most of those > require some kind of autoconf test. I'm sure you had some specific code in mind when you wrote this. I assumed the build system would have the appropriate compiler options for the desired compliance level. Should I compile with '-std=c99 -pedantic-errors' to check, or do you have other options in mind? > 2. Let's avoid float and double (and struct timeval). There's no > reason why we can't fit enough precision in a uint32 to count > elapsed time in milliseconds for a build: that gives 50 days or > so. GNU make still supports running on systems where there is > no floating point support (see the NO_FLOAT #define). Although > I haven't tested it in a while. I was aware of this since your first email. I wanted to know of the general idea is OK. I will change this, too. > 3. The use of "$" tokens in printf() statements is likely > problematic from a portability standpoint. It seems like this > should be relatively easy to avoid. I'll change them into simple format specifiers, in spite of the repetitions. > 4. If the printed string contains text then it needs to be marked > for translation (with the "_(...)" macro). Since the profiling info should be machine parsable, I think the only tran
Re: [bug #40639] GNU Make with profiling information
To some, using a spreadsheet might not seem like the most worthwhile way to visualise timing information. If it was me, I'd be far more concerned about whether I could write a script that could easily cope with all this information. Builds with hundreds of thousands of targets were common for me at one point and nowadays I do android stuff - how much is that? I think it's somewhere around 36,000. This scale makes spreadsheets relatively unimportant as an analysis tool and makes it necessary to pass information through a script to first extract or summarise the information to a level where humans can deal with it. Hence: a) an absolute start time and b) a duration ...are easy to process in scripts to reconstruct whatever form one needs - a spreadsheet for you and a different kind of special graph for me. Both examples of a profiling feature for make that I'm aware of already use this format to good effect. It's also worth trying to produce these figures as each job finishes and then throw them away because then the build doesn't have to finish before one is able to process the data. You might use it, for example to provide progress information. e.g. if you keep information from a previous build and combine it with profiling information coming out of the new build you can guess how long is left. Regards, Tim On 14 January 2014 13:48, Eddy Petrișor wrote: > > > 2014/1/12 Paul Smith : > >> On Wed, 2013-12-18 at 13:28 +0200, Eddy Petrișor wrote: >>> Could you please confirm if the general direction of the the is OK in >>> the latest patch I sent? >> >> Conceptually it seems OK. I'm still not jazzed about having any more >> than one output format, and I'd prefer that format to be in a >> more-or-less readable form, more like the "long" form than the others. > > If that will be the only format, then it would mean always imposing a lot > more more work on the information processing stage due to necessary > filtering and transformations to fit a format accepted or easily parsed in a > tool such as Oocalc, Gnumeric or Excel. > > Although human readable seems nice and understandable, it is the least > machine parseable, hence my choice for the 'simple' format to be default. > > >> >> I think the output should go in the standard make output format, so >> something like: >> >> make[]: : >> >> Or, alternatively: >> >> []: >> >> Also I think it's enough to show the start offset and the elapsed time. >> End offset is not necessary IMO. > > Unfortunately, depending on the used tools, when processing the information > the end time is necessary. For instance, in Microsoft Excel the only way to > display graphs for intervals is via a graph designed for visualising stocks' > variation (and it even forces the insertion of an extra field). > > Oocalc is fine with start and stop, but for the graphs look awful and are > unusable with absolute values (it scales so the entire 0-timestamp interval > is visible, so a difference of a few seconds is invisible on the graph), so > relative values are better here. > > OTOH, relative time stamps or just durations are useful for a human eye > examination, since is easy to spot offenders that way. > > > These are three different scenarios which I myself encountered and had in > mind when designing the code the way I did. > >> >> I'm unsure about the PID. This is the pid of the make process so I'm >> not sure what the goal is. Is it to be able to collect all the times >> together maybe? > > The goal is to be able to: > - spot targets evaluated redundantly in a recursive makefile in different > processes but on the same recursion level (these targets could be candidates > to be moved in a parent make invocation) > - spot wasteful/needless recursive calls (e.g. several targets called in > different make processes when they could be grouped in a single call) > - be able to analyse a single make invocation or a call sub-tree > >> >> Is it necessary to dump all the output times at the end? Doing so >> requires that we increase the size of the file structure to hold the >> information, and this is already large AND the most common structure in >> memory; there's one for every single target which for non-recursive >> builds can get really big. I'm trying to keep memory usage under >> control. >> >> If instead of that we print the information after each target is >> complete we can shift the storage of this information out of the file >> structure and into the commands structure or similar. To me it seems >> more useful to keep the elapsed time info right next to the command >> output rather than dumping it all at the end. > > I'm afraid I am missing some details of the implementation so I can't answer > that question in any meaningful way. > I will have to look into the code, but if a single target does NOT have > multiple commands structures, it should work. > > Any pointers to the appropriate code area or suggestions would be welcome. > >> Some other comments: >>
Re: [bug #40639] GNU Make with profiling information
I forgot to say that start times don't need to be absolute times - only relative to the start of the top level gmake if possible. That creates a problem for submakes I suppose. I would guess that one could put the absolute build start time in an environment variable like MAKE_START_TIME and then use that in every submake to get the relative start time. I haven't looked at the patch - perhaps it's doing this? In any case, fixed/floating point seconds since 1970 is the nicest format to process from scripts in my experience. Regards, Tim On 14 January 2014 15:49, Tim Murphy wrote: > To some, using a spreadsheet might not seem like the most worthwhile > way to visualise timing information. > > If it was me, I'd be far more concerned about whether I could write a > script that could easily cope with all this information. Builds with > hundreds of thousands of targets were common for me at one point and > nowadays I do android stuff - how much is that? I think it's > somewhere around 36,000. > > This scale makes spreadsheets relatively unimportant as an analysis > tool and makes it necessary to pass information through a script to > first extract or summarise the information to a level where humans can > deal with it. > > Hence: > a) an absolute start time and > b) a duration > > ...are easy to process in scripts to reconstruct whatever form one > needs - a spreadsheet for you and a different kind of special graph > for me. Both examples of a profiling feature for make that I'm aware > of already use this format to good effect. > > It's also worth trying to produce these figures as each job finishes > and then throw them away because then the build doesn't have to finish > before one is able to process the data. You might use it, for example > to provide progress information. e.g. if you keep information from a > previous build and combine it with profiling information coming out of > the new build you can guess how long is left. > > Regards, > > Tim > > > On 14 January 2014 13:48, Eddy Petrișor wrote: >> >> >> 2014/1/12 Paul Smith : >> >>> On Wed, 2013-12-18 at 13:28 +0200, Eddy Petrișor wrote: Could you please confirm if the general direction of the the is OK in the latest patch I sent? >>> >>> Conceptually it seems OK. I'm still not jazzed about having any more >>> than one output format, and I'd prefer that format to be in a >>> more-or-less readable form, more like the "long" form than the others. >> >> If that will be the only format, then it would mean always imposing a lot >> more more work on the information processing stage due to necessary >> filtering and transformations to fit a format accepted or easily parsed in a >> tool such as Oocalc, Gnumeric or Excel. >> >> Although human readable seems nice and understandable, it is the least >> machine parseable, hence my choice for the 'simple' format to be default. >> >> >>> >>> I think the output should go in the standard make output format, so >>> something like: >>> >>> make[]: : >>> >>> Or, alternatively: >>> >>> []: >>> >>> Also I think it's enough to show the start offset and the elapsed time. >>> End offset is not necessary IMO. >> >> Unfortunately, depending on the used tools, when processing the information >> the end time is necessary. For instance, in Microsoft Excel the only way to >> display graphs for intervals is via a graph designed for visualising stocks' >> variation (and it even forces the insertion of an extra field). >> >> Oocalc is fine with start and stop, but for the graphs look awful and are >> unusable with absolute values (it scales so the entire 0-timestamp interval >> is visible, so a difference of a few seconds is invisible on the graph), so >> relative values are better here. >> >> OTOH, relative time stamps or just durations are useful for a human eye >> examination, since is easy to spot offenders that way. >> >> >> These are three different scenarios which I myself encountered and had in >> mind when designing the code the way I did. >> >>> >>> I'm unsure about the PID. This is the pid of the make process so I'm >>> not sure what the goal is. Is it to be able to collect all the times >>> together maybe? >> >> The goal is to be able to: >> - spot targets evaluated redundantly in a recursive makefile in different >> processes but on the same recursion level (these targets could be candidates >> to be moved in a parent make invocation) >> - spot wasteful/needless recursive calls (e.g. several targets called in >> different make processes when they could be grouped in a single call) >> - be able to analyse a single make invocation or a call sub-tree >> >>> >>> Is it necessary to dump all the output times at the end? Doing so >>> requires that we increase the size of the file structure to hold the >>> information, and this is already large AND the most common structure in >>> memory; there's one for every single target which for non-recursive >>> builds can get really big. I'm trying to
Re: Re: win32 compilation of make 4.0 source code
> From: "Mark Brown" > Cc: , > > Date: Mon, 13 Jan 2014 22:56:10 -0800 > > I showed some of the output when this new windows/dos make is run > from the command prompt, in the original message. Sorry, I thought that was from the Cygwin shell, since you asked whether this Make is supposed to work with Cygwin. > Why not just post a step by step description of how to compile > make in Windows 7 64, post some output of its operation, > and clear everything up ? I don't know how to build it with MSVC, sorry. I use MinGW port of GCC. You could try using the build_w32.bat batch file. But I think your build is OK, it's something else that causes the problem. > Also, can you describe what the series of failed process_begin's indicates ? > Are they emanating from inside the make code or from executables invoked by > make ? These messages come from Make, and they tell that Make failed to invoke some program that the Makefile instructed it to. > === > process_begin: CreateProcess(NULL, uname, ...) failed. > make: > process_begin: CreateProcess(NULL, uname -a, ...) failed. > make: > process_begin: CreateProcess(NULL, cygpath C:\zzz_13.12.1_gener > make: > process_begin: CreateProcess(NULL, pwd, ...) failed. > make: > process_begin: CreateProcess(NULL, basename "", ...) failed. > make: > process_begin: CreateProcess(NULL, pwd, ...) failed. > make: > process_begin: CreateProcess(NULL, basename "", ...) failed. Do you have uname.exe, cygpath.exe, pwd.exe, and basename.exe somewhere on your PATH? If not, that's the reason for those failures: Make looks for these programs, but cannot find them. If that doesn't help, please show the Makefile you are trying to use and the full error messages by Make when you run it. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: RE: win32 compilation of make 4.0 source code
> From: Pavel Fedin > Date: Tue, 14 Jan 2014 11:53:15 +0400 > Cc: bug-make@gnu.org > Obviously, you are trying to execute Makefile written for UNIX systems, are > you ? This makefile relies on UNIX shell commands like uname, pwd, basename, > etc. Right ? > In order to run this Makefile, you need Cygwin or MinGW32 environment. Well, there are native Windows ports of these commands as well (e.g., on the GnuWin32 site). But I'm not sure whether Mark wants to run native or Cygwin tools. Actually, if Mark wants to run Cygwin tools, I'd suggest to install the Cygwin build of Make, it will have less "issues" with Cygwin programs than the native build of Make. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #40639] GNU Make with profiling information
2014/1/14 Tim Murphy > > To some, using a spreadsheet might not seem like the most worthwhile > way to visualise timing information. That's why I thought it can be useful to provide the information in various formats. I found useful the graphs provided via a graph from data in spreadsheet, you need the info to scale to some higher level. I think the best compromise are the different formats provided by my latest patch version. > > If it was me, I'd be far more concerned about whether I could write a > script that could easily cope with all this information. Builds with > hundreds of thousands of targets were common for me at one point and > nowadays I do android stuff - how much is that? I think it's > somewhere around 36,000. > > This scale makes spreadsheets relatively unimportant as an analysis > tool and makes it necessary to pass information through a script to > first extract or summarise the information to a level where humans can > deal with it. > > Hence: > a) an absolute start time and > b) a duration That is provided by the 'simple' format. > > ...are easy to process in scripts to reconstruct whatever form one > needs - a spreadsheet for you and a different kind of special graph > for me. Both examples of a profiling feature for make that I'm aware > of already use this format to good effect. > > It's also worth trying to produce these figures as each job finishes > and then throw them away because then the build doesn't have to finish > before one is able to process the data. You might use it, for example > to provide progress information. e.g. if you keep information from a > previous build and combine it with profiling information coming out of > the new build you can guess how long is left. I think this fits with Paul's suggestion to keep the info in the commands structure. I am unsure if this would do the job, but I see the benefit in providing the info ASAP, so if I can avoid any unnecessary delays, I will. I have tried the sort of scenario you think of in one of the build systems I maintain and a simple grep through stderr for '^PROFILING' can isolate the profiling info during the build. > I forgot to say that start times don't need to be absolute times - > only relative to the start of the top level gmake if possible. That > creates a problem for submakes I suppose. > > I would guess that one could put the absolute build start time in an > environment variable like MAKE_START_TIME and then use that in every > submake to get the relative start time. > I haven't looked at the patch - perhaps it's doing this? I tried this in local branch, but wasn't successful (code is not published for that attempt to avoid confusion around which code to review). > In any case, fixed/floating point seconds since 1970 is the nicest > format to process from scripts in my experience. That is what is printed now, where applicable. -- Eddy Petrișor ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [PATCH] Fix output-sync option on EMX
> From: Pavel Fedin
> Date: Tue, 14 Jan 2014 11:11:35 +0400
>
> This is part of my spawn-patch for Make. The purpose of this piece is to
> add missing support for output-sync option to spawn()-based flavors
> (currently only EMX).
Thanks, but does EMX support output-sync? If not, this fragment:
+ /* Divert child output if output_sync in use. */
+ if (child->output.syncout)
+{
+ if (child->output.out >= 0)
+outfd = child->output.out;
+ if (child->output.err >= 0)
+errfd = child->output.err;
+}
+
should be conditioned on NO_OUTPUT_SYNC. Otherwise we are breaking
the EMX build of Make.
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Re: [PATCH] Fix output-sync option on EMX
On Tue, Jan 14, 2014 at 12:41 PM, Eli Zaretskii wrote: > Thanks, but does EMX support output-sync? Didn't he just say "The purpose of this piece is to add missing support for output-sync option to [...] EMX"? David ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [PATCH] Fix output-sync option on EMX
> From: David Boyce > Date: Tue, 14 Jan 2014 13:13:13 -0500 > Cc: Pavel Fedin , bug-make > > On Tue, Jan 14, 2014 at 12:41 PM, Eli Zaretskii wrote: > > Thanks, but does EMX support output-sync? > > Didn't he just say "The purpose of this piece is to add missing > support for output-sync option to [...] EMX"? The part you replaced with "..." sounds like an important qualifier to me. I also have hard time believing that these 4 lines is all it takes to support output-sync on EMX. Finally, if that is indeed what EMX needs to support output-sync, that should be tested in the EMX build, not in a Cygwin build. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: make doesn't complain if target cannot be built
Am Dienstag, 14. Januar 2014, 08:12:38 schrieb Paul Smith: > Can you add the prerequisite to the pattern rules? > > %.o : %.c generated.h > $(COMPILE.c) ... > %.o : %.cpp generated.h > $(COMPILE.cpp) ... > > This has the definite potential downside that if "generated.h" changes > then _every_ object file will rebuild, even if they do not use it. But > maybe they all use it anyway. generated.h will only be used by some object files, so this seems to be no good way > Alternatively you could use order-only prerequisites: > > %.o : %.c | generated.h > $(COMPILE.c) ... > %.o : %.cpp | generated.h > $(COMPILE.cpp) ... > > Now you have the opposite problem: generated.h will be rebuilt BUT none > the object files will be recompiled (if the only thing that's changed is > the generated.h file). I think this issue can be avoided by using automatically generated dependency files. > Really, I'm not sure I see the ultimate problem. First, it seems that > you will always need to define header files, etc., so you will already > have plenty of rules of the form: > > foo.o: bar.h biz.h > > and so this issue already exists. As I'm using generated dependency files which at least don't exist when make is run for the 1st time. So missing sources will be detected. For further runs, there will be an explicit dependency for each object file which recognizes, whether the source file is missing. > Second, if all you're worried about is someone adding a bogus file to > the makefile list of objects, that doesn't seem like a real issue; sure, > it won't be caught here but the build will still fail (presumably you're > using that list of objects to construct something else and THAT will not > work if one of the object files is missing). Yes, this is catched by the linker. But I think this is not optimal (and not what I expect). > If you really want to catch it early you can just do a specific check to > make sure all the listed files exist: > > SOURCES := foo.c foo.cpp foo.asm ... > > MISSING := $(filter-out $(wildcard $(SOURCES)),$(SOURCES)) > ifneq (,$(MISSING)) > $(error Missing files: $(MISSING)) > endif > > It's definitely true that you won't be able to get the traditional make > error message; I just don't think it's worth the hoops you'll need to > jump through to make that happen. > > But maybe you have some other requirement. I've tested your second hint (order-only prerequisites in implicit pattern rules) in combination with automatically generated dependency files: ---Makefile--- .PHONY: all clean OBJS := foo.o bar.o all: $(OBJS) $(OBJS): CPPFLAGS += -MMD -MF $(@:%=%.d) -MP -MT $(@:%=%.d) -MT $(@) %.o: %.c | generated.h $(COMPILE.c) $(OUTPUT_OPTION) $< generated.h: generated.x touch $(@) clean: $(RM) $(OBJS) $(OBJS:%=%.d) generated.h -include $(OBJS:%=%.d) ---EOF--- This avoids $(OBJS) to become a target (unless the dependency files are generated). This seems to work correctly for all cases I tested If interested, see attached tar archive and run "run_tests.sh". thanks Christian make_missing_implicit.tar.gz Description: application/compressed-tar ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [PATCH] Fix output-sync option on EMX
Hello, Eli. Tuesday, January 14, 2014, 22:50:28 you wrote: > The part you replaced with "..." sounds like an important qualifier to > me. > I also have hard time believing that these 4 lines is all it takes to > support output-sync on EMX. If you remember my original spawn-patch, all it does is replacing #ifdef __EMX__ with #if defined __EMX__ || defined __CYGWIN__ consequently, Cygwin version of Make starts behaving in the same way as it would on EMX (well, except shell simulation magic). With old spawn-patch make v4 perfectly worked except it failed output-sync test. I have examined related changes and found out that fork()-based code performs output redirection, and spawn() version simply forgets doing it. So, i have moved this fragment out of #ifdef's, and everything worked like a charm. > Finally, if that is indeed what EMX needs to support output-sync, that > should be tested in the EMX build, not in a Cygwin build. There is a little problem with this. It looks like nobody in the world uses OS/2 any more. At least for compiling something. My concerns are: 1. EMX is actually a POSIX environment for OS/2. 2. Cygwin is a POSIX environment for Windows. 3. Cygwin is (well, nearly) 100% compatible with EMX because both Cygwin and EMX implement spawn() semantics. Consequently, if something works on Cygwin, it will work on EMX. Make does not use anything else additional except spawn() on these two environments. And anoher concern: despite we do not have possibility to test EMX build, this way we can test its supposed functionality on Cygwin, which is quite close. Isn't it better than just letting EMX version to bitrot and die ? And one more: if you take a look at the code, this is the only code fragment related to output-sync which falls under any OS-specific #ifdef's. The rest is pretty generic. P.S. This '...' actually reads "spawn()-based flavours (currently only EMX)'. So nothing additional. -- С уважением, Pavel mailto:pavel_fe...@mail.ru ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[PATCH] Fix output-sync option on EMX - updated
Hello!
> Thanks, but does EMX support output-sync? If not, this fragment:
>
> + /* Divert child output if output_sync in use. */
> + if (child->output.syncout)
> +{
> + if (child->output.out >= 0)
> +outfd = child->output.out;
> + if (child->output.err >= 0)
> +errfd = child->output.err;
> +}
> +
>
> should be conditioned on NO_OUTPUT_SYNC. Otherwise we are breaking the
> EMX build of Make.
I have rechecked. Actually NO_OUTPUT_SYNC is defined only by handmade
config.h files for DOS, VMS and Amiga. EMX uses configure script, so
NO_OUTPUT_SYNC will not be defined.
However, indeed, there is rational seed in what you say. Since this code
actually goes to generic part, it will be useful to be able to disable this
code, just in case.
Please take the updated patch. I have verified it to build by supplying
CPPFLAGS=-DNO_OUTPUT_SYNC to configure.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
make-fix-output-sync-emx.diff
Description: Binary data
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
