Re: cvs commit: apr-util Makefile.in
[EMAIL PROTECTED] wrote: dreid 2004/03/09 09:57:35 Modified:.Makefile.in Log: This seems to have been lost in the changeover. If there is another way of accomplishing this then I failed to find one and the code in configure seems to point at this being a simple oversight. With this small patch we can build on beos again. Revision ChangesPath 1.85 +2 -1 apr-util/Makefile.in Index: Makefile.in === RCS file: /home/cvs/apr-util/Makefile.in,v retrieving revision 1.84 retrieving revision 1.85 diff -u -r1.84 -r1.85 --- Makefile.in 21 Feb 2004 00:43:56 - 1.84 +++ Makefile.in 9 Mar 2004 17:57:35 - 1.85 @@ -17,6 +17,7 @@ TARGET_LIB = [EMAIL PROTECTED]@.la INSTALL_SUBDIRS = @APR_XML_DIR@ EXTRA_SOURCE_DIRS = @APR_XML_DIR@ [EMAIL PROTECTED]@ TARGETS = $(TARGET_LIB) aprutil.exp export_vars.h @@ -69,7 +70,7 @@ chmod 755 $(DESTDIR)$(bindir)/apu-config $(TARGET_LIB): $(OBJECTS) - $(LINK) @lib_target@ $(ALL_LIBS) + $(LINK) @lib_target@ $(ALL_LIBS) $(EXTRA_OS_LINK) Thanks, David! When I finally got python installed on my aix boxes, apr-util 1.0 apps were busted due to missing libraries. This resolved it.
Re: cvs commit: apr-util Makefile.in
Greg Stein wrote: On Sat, Feb 17, 2001 at 04:10:55PM -, [EMAIL PROTECTED] wrote: ... --- Makefile.in 2001/02/01 21:54:22 1.32 +++ Makefile.in 2001/02/17 16:10:54 1.33 @@ -55,3 +55,6 @@ exports.c: $(EXPORT_FILES) (cat $(EXPORT_FILES) | ../build/buildexports.sh ..) $@ + +# wtf does this have to be explicit +exports.lo: exports.c What OS and make are you using? 3.2-STABLE FreeBSD, using the make that comes with it. Did you use the debug flags to 'make' to see wtf it was thinking? No. The amount of output that produces from these makefiles is ridiculous. I could be persuaded to look but it isn't high on my list! I can't imagine it would need to be explicit. Too many other things would break. Possibly, it is related to the very dynamic nature of exports.c. Possibly, it grabbed all the timestamps at the start of the make, and didn't notice the updated timestamp after exports.c was rebuilt. ??? That seems rather unlikely! Make wouldn't work at all in this case. Did a second 'make' run fix it? Or did it just persist in being broken? (if the former, it might support my hypothesis of grabbing timestamps) It persisted in being broken. Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: cvs commit: apr-util Makefile.in
[EMAIL PROTECTED] writes: Index: Makefile.in === RCS file: /home/cvs/apr/Makefile.in,v retrieving revision 1.40 retrieving revision 1.41 diff -u -r1.40 -r1.41 --- Makefile.in 2001/02/16 10:17:10 1.40 +++ Makefile.in 2001/02/17 16:10:55 1.41 @@ -61,7 +61,7 @@ fi \ fi -$(TARGET_EXPORTS): +$(TARGET_EXPORTS): include/*.h Solaris doesn't like this :( make[3]: *** No rule to make target `include/*.h', needed by `apr.exports'. Stop. make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 --end of /export/home/trawick/regress/logs/make.stderr- -$(TARGET_EXPORTS): +$(TARGET_EXPORTS): include/*.h $(AWK) -f @APR_SOURCE_DIR@/helpers/make_export.awk include/*.h $@ ; again -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: apr-util Makefile.in
I've reversed those changes. On Sat, Feb 17, 2001 at 03:35:18PM -0500, Jeff Trawick wrote: [EMAIL PROTECTED] writes: Index: Makefile.in === RCS file: /home/cvs/apr/Makefile.in,v retrieving revision 1.40 retrieving revision 1.41 diff -u -r1.40 -r1.41 --- Makefile.in 2001/02/16 10:17:10 1.40 +++ Makefile.in 2001/02/17 16:10:55 1.41 @@ -61,7 +61,7 @@ fi \ fi -$(TARGET_EXPORTS): +$(TARGET_EXPORTS): include/*.h Solaris doesn't like this :( make[3]: *** No rule to make target `include/*.h', needed by `apr.exports'. Stop. make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 --end of /export/home/trawick/regress/logs/make.stderr- -$(TARGET_EXPORTS): +$(TARGET_EXPORTS): include/*.h $(AWK) -f @APR_SOURCE_DIR@/helpers/make_export.awk include/*.h $@ ; again -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien... -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr-util Makefile.in STATUS aprutil.dsp configure.in libaprutil.dsp
On Thu, Jan 18, 2001 at 04:34:44AM -, [EMAIL PROTECTED] wrote: wrowe 01/01/17 20:34:44 Modified:.STATUS .Makefile.in STATUS aprutil.dsp configure.in libaprutil.dsp Log: Upon a vote of 5 to 3 for eliminating the src/ structure, and unanimous consent that apr and apr-util should share a common structure, the src/ branch of apr-util is orphaned. These files will be deleted at T+1200 from the time of this commit, so if you have changes out there, save them in the new structure or set them aside. cvs update will destroy them as of tommorow morning. Win32 build is corrected, unix may (?) be corrected (please review.) ... --- Makefile.in 2001/01/09 09:41:26 1.17 +++ Makefile.in 2001/01/18 04:34:43 1.18 @@ -10,7 +10,7 @@ # bring in rules.mk for standard functionality @INCLUDE_RULES@ -SUBDIRS = src . test build +SUBDIRS = buckets crypto dbm encoding hooks uri xml . test build CLEAN_TARGETS = $(TARGET_EXPORTS) DISTCLEAN_TARGETS = config.cache config.log config.status \ @@ -24,7 +24,7 @@ delete-lib: @if test -f $(TARGET_LIB); then \ - objects=`find src -name '*.lo' -a -newer $(TARGET_LIB)` ; \ + objects=`find . -name '*.lo' -a -newer $(TARGET_LIB)` ; \ if test -n $$objects; then \ echo Found newer objects. Will relink $(TARGET_LIB). ; \ echo $(RM) -f $(TARGET_LIB) ; \ @@ -33,7 +33,7 @@ fi $(TARGET_LIB): - @objects=`find src -name '*.lo'` ; \ + @objects=`find . -name '*.lo'` ; \ echo $(LINK) $$objects ; \ $(LINK) -rpath $(libdir) $$objects If you're going to advocate the non-src position, then you better get the damned thing right. . is not going to work. Think about the test directory. -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr-util Makefile.in
[EMAIL PROTECTED] writes: gstein 00/12/12 03:05:33 Modified:.Makefile.in Log: auto-rebuild the exports file when a header changes Revision ChangesPath 1.6 +14 -3 apr-util/Makefile.in Index: Makefile.in === RCS file: /home/cvs/apr-util/Makefile.in,v retrieving revision 1.5 retrieving revision 1.6 diff -u -u -r1.5 -r1.6 --- Makefile.in 2000/12/06 05:02:13 1.5 +++ Makefile.in 2000/12/12 11:05:32 1.6 ... @@ -33,7 +34,17 @@ echo $(LINK) $$objects ; \ $(LINK) -rpath $(libdir) $$objects -aprutil.exports: +delete-exports: + @if test -f $(TARGET_EXPORTS); then \ + headers=`find include/*.h -maxdepth 0 -newer $(TARGET_EXPORTS)` ; \ + if test -n $$headers; then \ + echo Found newer headers. Will rebuild $(TARGET_EXPORTS). ; \ + echo $(RM) -f $(TARGET_EXPORTS) ; \ + $(RM) -f $(TARGET_EXPORTS) ; \ + fi \ + fi This breaks FreeBSD (3.4, at least), which doesn't support find -maxdepth. If I understand correctly, -maxdepth 0 isn't really necessary here because there will be no directories fed to find so there can't be any traversal (no chance to test at the moment though; maybe in an hour when I get back from an errand). -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: apr-util Makefile.in
Cool. Thx! -g On Tue, Dec 12, 2000 at 03:12:41PM -, [EMAIL PROTECTED] wrote: trawick 00/12/12 07:12:40 Modified:.Makefile.in Log: Get rid of -maxdepth 0 on the find invocation. This breaks on Tru64 and FreeBSD, and I can't tell that it helps anyway. Revision ChangesPath 1.8 +1 -1 apr-util/Makefile.in Index: Makefile.in === RCS file: /home/cvs/apr-util/Makefile.in,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- Makefile.in 2000/12/12 11:13:00 1.7 +++ Makefile.in 2000/12/12 15:12:35 1.8 @@ -38,7 +38,7 @@ delete-exports: @if test -f $(TARGET_EXPORTS); then \ - headers=`find include/*.h -maxdepth 0 -newer $(TARGET_EXPORTS)` ; \ + headers=`find include/*.h -newer $(TARGET_EXPORTS)` ; \ if test -n $$headers; then \ echo Found newer headers. Will rebuild $(TARGET_EXPORTS). ; \ echo $(RM) -f $(TARGET_EXPORTS) ; \ -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr-util Makefile.in
No, distclean means clean the directories in preparation of a release. For example, the one for rsync does distclean: clean rm -f config.h config.cache config.status Makefile I have seen reallyclean used as a target to remove all generated files, but it isn't a standard either. extraclean seems fine. Okay. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: cvs commit: apr-util Makefile.in
On Tue, Dec 05, 2000 at 04:38:27PM -0800, [EMAIL PROTECTED] wrote: We have three levels of cleaning that need to be expressed: 1) clean out the .o files [before rebuilding] 2) clean out the results of running ./configure (restore everything to the same point that you unpacked apache.org/dist/aprutil-1.0.tar.gz) 3) return to the point right after a CVS checkout Step 2 does not exist in Apache as it now stands, and nobody has been clamoring for it so far. It has never existed AFAICS. As a few people have mentioned, distclean (type (2)) is pretty common (Roy mentioned rsync, I'll chime in with Python, Neon, Berkeley DB, PHP, Python's MySQL interface, and all automake-based projects such as Subversion). And I *do* see that Apache has (2) and it is called distclean. :-) As for step 3, I would be much happier with an external program like cvsclean. We only have about six files in the whole tree to deal with (3). I went for the simple, straightforward approach. I believe that we *do* need these three types of cleaning. Does this make sense to you? Sure. I am still not convinced that we need all three, and regardless, we shouldn't be duplicating files, so pleast fix that. As I mentioned in my previous reply... we are not duplicating any files in those lists. I presume that your note implies your veto is lifted? Thanks, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr-util Makefile.in
1) clean out the .o files [before rebuilding] 2) clean out the results of running ./configure (restore everything to the same point that you unpacked apache.org/dist/aprutil-1.0.tar.gz) 3) return to the point right after a CVS checkout Step 2 does not exist in Apache as it now stands, and nobody has been clamoring for it so far. It has never existed AFAICS. And I *do* see that Apache has (2) and it is called distclean. :-) Here are the files cleaned by Apache's distclean: DISTCLEANFILES = include/config_auto.h modules.c aclocal.m4 buildmk.stamp \ configure generated_lists include/ap_config_auto.h \ include/ap_config_auto.h.in include/ap_config_path.h install-sh That includes configure at least, which is not a part of step 2. We only have about six files in the whole tree to deal with (3). I went for the simple, straightforward approach. Then please make it common in all of the Makefiles, Apache, apr, apr-util, pcre, sdbm, expat-lite, etc. I presume that your note implies your veto is lifted? Yes. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: cvs commit: apr-util Makefile.in
On Tue, 5 Dec 2000 [EMAIL PROTECTED] wrote: Modified:.Makefile.in Log: aprutil in the distribution form does not want to remove configure or aprutils.exports (these two files are part of the distribution and users cannot typically regenerate them). But the developers' extraclean target will do it. WHAT!?!?!?! Distclean is meant to bring us back to what we had when we did a cvs checkout. Actually, you'd use cvsclean for that (dunno where it is today, before the move it was in src/helpers). Since this has come up several times in the past, here is the definition of distclean, as commonly agreed upon: The target distclean is intended to remove all files which were created by configuring or building the program. - Sascha
Re: cvs commit: apr-util Makefile.in
WHAT!?!?!?! Distclean is meant to bring us back to what we had when we did a cvs checkout. If you just want to clean your directory use make clean, not make distclean. This is the exact same syntax and rules that Apache and APR have always used. AFAIK, this is basically a standard and we shouldn't be re-inventing things. -1 No, distclean means clean the directories in preparation of a release. For example, the one for rsync does distclean: clean rm -f config.h config.cache config.status Makefile I have seen reallyclean used as a target to remove all generated files, but it isn't a standard either. extraclean seems fine. Roy
