Re: Generating Prerequisites Automatically
Hi, Ted Sorry, I sent this message directly to you, not to the list. Yes, your are partialy right, my way has several problems, I've encountered in a short time after submitting it to the list. All inluded makefiles share .DEFAULT rule with each other and the master makefile, so multiple 'redefined' warnings are issued during make. But it works as the last ( the actual ) default rule in case of 'missing header' error is exactly a rule to remake makefile that contains stale dependency. It seems to me > Hello Peter, > > I'm just another user but I subscribe to the bug-make list to keep up with > developments. > > I would recommend against having any explicit rule for the dependency > files. > > In fact, in my (extremely complex) makefile I prefix the include line for > dependencies with a "-" so that MAKE does not generate an error if the file > is not found: > ># include all dependency files: >-include $(ALL_DEPS) But if error is generated, it actualy exists. Just skip it is not the best solution, it think. Note that error is stale dependency in dependency file, not missing dependency file which is generated automatically without any errors. > Instead, I use a trick Paul Smith describes elsewhere, which is to create > the dependency files concurrently with compilation. That way, if the Please, point me to that trick. Am I reinventing the wheel ? =) And my purpose is to generate dependency file only in case of real need, not on every build. Actualy the fact, that pushed me pay close attention to make is that I develop quite big (600 kb unpacked sources) project on quite poor (celeron 300) machine, so even dependency generation takes about 30 seconds. > source has been modified, the dependency file will be re-created for the > next round. Note that many C compilers have an option to print out > dependency information in the format that would be expected by BSD-style > makefiles. In my own makefiles, I take that output and process it a bit > with perl. Is BSD-style makefiles dependency information different from GNU makefiles dependency information ? Anything more than target.o: source1 source2 ... > However for more complicated dependency generation, such as that associated > with fortran 90, you may need a special dependency rule. In that case, I > would avoid having the dependency file depend on anything other than the > source, in order to avoid exactly the problem you describe. Yes, but problem goes far -- imagine you have source: // foo.cc #include "foo.h" // foo.h #include "bar.h" // bar.h // just another header so we have dependecy generated: #foo.P foo.o: foo.cc foo.h bar.h than we update project this way: // bar.h #include "xxx.h" // xxx.h // just another header when you 'make' all is done right -- foo.o is remade than we update project this way: // xxx.h ... cout << "xxx.h online\n"; but next 'make' will not remake foo.o cause make has no dependency foo.o: xxx.h Even if your dependency file ( foo.P in this example ) depends on .cc like this: foo.P: foo.cc or more realistic %.P: %.cc $(CXX) $(CXXFLAGS) -MM $< > $@ You will fail, cause we have not touched foo.cc So, you see -- dependency file should depend not only on primary file, but also on all files primary file depends like this: #foo.P foo.o foo.P: foo.cc foo.h bar.h The solution I've sent was exactly to this problem =) > Ted -- Sincerely yours Peter Kerzum ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Generating Prerequisites Automatically
"Peter A.Kerzum" wrote: >... > > Instead, I use a trick Paul Smith describes elsewhere, which is to create > > the dependency files concurrently with compilation. That way, if the > > Please, point me to that trick. Am I reinventing the wheel ? =) > And my purpose is to generate dependency file only in case of real need, not > on every build. >... Look at http://make.paulandlesley.org/autodep.html, indicated in Paul's signature. Johan Bezem CSK Software AG ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Use of $* in computed dependencies
This is not a bug, but a neat feature that would open the door to improved functionality, as far as I can see. The following makefile doesn't do what I had hoped it would: all:b.logvsh b_depend := a.raw.mod %.logvsh: $($*_depend) %.mod @echo make $@ %.raw.mod: @echo make $@ %.mod: @echo make $@ Here the first target b.logvsh matches the %.logvsh rule. It makes implied target b.mod, and finally it makes b.logvsh. The printout is: % make -r make b.mod make b.logvsh Unfortunately, I wanted b.logvsh to also depend on a.raw.mod. What I wanted to say is that, in general, %.logvsh targets depend only on their corresponding %.mod target, but if % happens to be "b", then also make b.logvsh dependent on b.raw.mod. I don't know of any other way to do this except through recursive calls to make, which I'm trying to avoid. I tried using $(%_depend) instead of $($*_depend), but that didn't work, either. I am using GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for sparc-sun-solaris2.7 Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000 Free Software Foundation, Inc. Is this feature worth considering for a future release? -- /---+---\ | Herbert Swan | Geoscience Operations | | Phillips Alaska, Inc. | | | 700 G Street | Phone: (907) 263-4043| | Anchorage, AK 99501 | Fax:(907) 265-1608| | Room: PTO 1340 | e-mail: [EMAIL PROTECTED] | \---+---/ ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
RE: Use of $* in computed dependencies
Sorry, I made a slight misstatement in my earlier post, corrected below. Thank you for reading this post. - This is not a bug, but a neat feature that would open the door to improved functionality, as far as I can see. The following makefile doesn't do what I had hoped it would: all:b.logvsh b_depend := a.raw.mod %.logvsh: $($*_depend) %.mod @echo make $@ %.raw.mod: @echo make $@ %.mod: @echo make $@ Here the first target b.logvsh matches the %.logvsh rule. It makes implied target b.mod, and finally it makes b.logvsh. The printout is: % make -r make b.mod make b.logvsh Unfortunately, I wanted b.logvsh to also depend on a.raw.mod. What I wanted to say is that, in general, %.logvsh targets depend only on their corresponding %.mod target, but if % happens to be "b", then also make b.logvsh dependent on a.raw.mod. I don't know of any other way to do --^- this except through recursive calls to make, which I'm trying to avoid. I tried using $(%_depend) instead of $($*_depend), but that didn't work, either. I am using GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for sparc-sun-solaris2.7 Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000 Free Software Foundation, Inc. Is this feature worth considering for a future release? -- /---+---\ | Herbert Swan | Geoscience Operations | | Phillips Alaska, Inc. | | | 700 G Street | Phone: (907) 263-4043| | Anchorage, AK 99501 | Fax:(907) 265-1608| | Room: PTO 1340 | e-mail: [EMAIL PROTECTED] | \---+---/ ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Use of $* in computed dependencies
On Thu, 23 Jan 2003, Herb W. Swan wrote: > > Sorry, I made a slight misstatement in my earlier post, corrected > below. Thank you for reading this post. > - > > This is not a bug, but a neat feature that would open the door > to improved functionality, as far as I can see. > > The following makefile doesn't do what I had hoped it would: > > all:b.logvsh > > b_depend := a.raw.mod > > %.logvsh: $($*_depend) %.mod > @echo make $@ > > %.raw.mod: > @echo make $@ > > %.mod: > @echo make $@ > HI Herb, I think I see what you are after here, because it looks similar to a problem that occurs with fortran 90 compiler-generated module files. Background, in case the .mod file doesn't come from fortran 90: http://www.theochem.uwa.edu.au/fortran/recompile/ In fortran 90 and above, compiling a fortran 90 file may generate a ".mod" file containing the interfaces and information needed by some other fortran file. Unfortunately the generated file may have a completely different basename than the original source file. In fact, there could be several generated files. It is possible to deal with this sort of situation without recursive make calls: %.depend: %.source run the makedepend script %.object: %.source usual compile command %.byproduct: # NO PATTERN DEPENDENCY HERE -- added explicitly below test for existence -- if not there, delete first dependency and call make recursively to regenerate first dependency include $(automatically_generated_depend_files) The makedepend script generates lines like the following: a.byproduct: b.object b.object: assorted include files and possibly other byproduct files In the fortran 90 case, there is an additional complication that a source change might not create any meaningful difference in the byproduct files, but the timestamp on the byproduct files changes anyway. So you need some method to compare byproduct files before and after the compile step to see if they've changed or not. I use a script called "byproduct_build.perl", attached below, to wrap around the compile command for this purpose. Note that if the byproduct files are out of date with respect to the object file, you'll still go into the %.byproduct rule, but if the byproduct file exists, the rule exits and files that depend on it won't get recompiled in a compilation cascade. Ted -- Ted Stern Engineering Applications Cray Inc. office: 206-701-2182 411 First Avenue South, Suite 600 cell: 206-383-1049 Seattle, WA 98104-2860 FAX: 206-701-2500 Debuggers' motto: Frango ut patefaciam -- I break in order to reveal byproduct_build.perl Description: byproduct_build.perl ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: EINTR causing useless recompilation?
Hello. I've finally gotten a chance to look at this more closely and the problem is that GNU make assume that SA_RESTART restarts all system calls which isn't true for solaris and I suspect isn't true for any System V based Unix. From looking at the linux sources it appears to restart everything but solaris seems to explicitly follow this language from the man page for sigaction: SA_RESTART If set and the signal is caught, functions that are interrupted by the execution of this signal's handler are transparently restarted by the system, namely fcntl(2), ioctl(2), wait(2), waitid(2), and the following functions on slow dev- ices like terminals: getmsg() and getpmsg() (see getmsg(2)); putmsg() and putpmsg() (see putmsg(2)); pread(), read(), and readv() (see read(2)); pwrite(), write(), and writev() (see write(2)); recv(), recvfrom(), and recvmsg() (see recv(3SOCKET)); and send(), sendto(), and sendmsg() (see send(3SOCKET). Otherwise, the function returns an EINTR error. A quick glance at the solaris sources and the disassembly of _stat vs. _read shows that read will restart itself but stat will not so the man page seem to accurately reflect what really going to happen. The source of the signals is the SIGCHLD handler installed by the jobserver logic. It's true that --disable-job-server will make this problem disappear but maybe it should be disabled by default on Solaris since it clearly doesn't work. > 2) Although your OS says it supports SA_RESTART, in fact it does not > properly implement it. I've already discovered another OS, Sequent > PTX, which defines the SA_RESTART constant in the system header > files, but it does not actually work. > > To the best of my knowledge SA_RESTART does work properly in Solaris > 2.7 and above (at least) on SPARC. I've never tried it on x86. I've seen failures with EINTR on Solaris sparc 2.7, 2.8 and solaris x86 2.8, so I don't think it works. The sparc failures are on machines with more than 15 CPUs but the Solaris x86 failures are on a 4 way system. I tried defining HAVE_BROKEN_RESTART on solaris but that doesn't compile since Solaris already has #define of stat to stat64 for large file support. Why not simply define atomic_stat and atomic_readdir all the time and use them throughout make? It wouldn't hurt any platform that never returns EINTR and would guarantee that it works on any platform with a more restricted definition of SA_RESTART. Thanks. tom ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: EINTR causing useless recompilation?
%% Tom Rodriguez <[EMAIL PROTECTED]> writes: tr> Hello. I've finally gotten a chance to look at this more closely tr> and the problem is that GNU make assume that SA_RESTART restarts tr> all system calls which isn't true for solaris and I suspect isn't tr> true for any System V based Unix. Yes, experimentations shows this to be the case. Unfortunately this means that Solaris is not compliant with the POSIX specs, which clearly state that any system call that can return EINTR must respect the SA_RESTART flag. tr> Why not simply define atomic_stat and atomic_readdir all the time tr> and use them throughout make? It wouldn't hurt any platform that tr> never returns EINTR and would guarantee that it works on any tr> platform with a more restricted definition of SA_RESTART. Thanks. I am going to implement a fix similar to this. It should take care of the worst of the problems. However, this does not mean that the problem is solved: GNU make makes many hundreds of different kinds of system calls, and many are hidden behind other user-level libc functions. If SA_RESTART cannot be relied upon to behave as per the POSIX spec then it seems like there's no fully reliable way to provide for this feature without doing prohibitive amounts of work. Thanks for the note! -- --- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
