Kent Boortz wrote: > Webstack reviewers, > > I'm part of the MySQL build team and worked with Sunanda on this > issue. I will try explain what this change is about. > > Those "sleep" commands could likely be removed. The reason they are > there is that I have seen "sleep" used to make time stamps "differ a > bit more" in other build setups, not to trigger a make rule, needed > when distributing source that are to build on many different operating > systems and "make" command incarnations. > > If those "sleep" statements are a problem, feel free to remove them. > In the case of Solaris I doubt they are needed. > > As you know, GNU autotools is a "generator". A developer runs those > tools, the one creating the source TAR to distribute runs it, but > those using that source TAR just to build from source doesn't run GNU > autotools. They run the pre-created "configure" script and use the > generated "Makefile.in" and other pre-generated files. > > The reason for the time stamps being needed is that in the webstack > build a large patch for adding dtrace support is applied. The patch > was created by someone working in a MySQL Bazaar repository tree, the > source you use is a released source TAR. The developer creating the > patch naturally runs GNU autotools himself and the time stamps on > files ends up being different that the same generated files in the > source TAR. > > And as it happens, after applying the dtrace patch time stamps has > changed in a way that some rule in "Makefile", derived from the "automake" > pre-created "Makefile.in", is triggered that try rerun GNU autotools, > and looks for the versions used when the source TAR was created. > > For a developer these extra rules to rerun different GNU autotools are > great, if doing changes in "configure.in", "Makefile.am" or other > input to any of the GNU autotools, the tools are automatically rerun. > Saves you from the mistake of not manually rerunning the tools, > wondering why your change "didn't take". I guess you all have been > there, loosing time on such simple mistakes. > > So the sequence of "touch" commands I found out by examining the make > rules in the "Makefile.in" files. And the order of course comes from > what file is input to what GNU auto tool and generates what other > file. So it is not just about the generated "configure" script, but > also the generated "Makefile.in" files and other files that is input > to, and generated from, GNU autotools. > > Note that some files generated by one of the GNU autotools might be > input to some other GNU autotool, that is why the exact sequence is > important when we "touch" files to avoid any rerun. > > I hope this made it clearer. > > I definitely don't mind if you remove the "sleep" commands. I would > not dare as I would fear other build "glitches" from removing them, > but if you know for sure that "touch foo; touch bar" would *never* > create the same time stamp on those from GNU make's perspective on > Solaris, please remove them.
GNU make builds a target when it does not exist or when it is older than a prerequisite. That's different than what you're suggesting -- that make rebuilds the target if it is not newer than the prerequisite. > I'm pretty sure no "sleep" commands are > needed, only left them there as I had other more important and urgent > tasks to do than digging deeper into this. I'm pretty sure that it was > only with Cygwin running on some old windows version it was really > needed, that had a one second time resolution, but to remove the > "sleep" commands I had to spend more time on making sure. > I believe that file modification times on the FAT filesystem have 2 second resolution. Maybe that was part of the problem. > The "touch" commands need to stay, unless you demand the guy producing > this patch to do it in a very different way, causing delay and lots of > work for him. I don't know enough about what the patch is really > changing, so I would not know if possible to create a "clean small > patch" that doesn't touch the files generated by GNU autotools, to > avoid a retrigger of GNU autotools. > no complaints about the touch commands > I would prefer you moved to a MySQL version that *does* contain dtrace > support, but that is just wishful thinking... :) > yeah, that's what we're working towards...
