Searched hist:99875 (Results 1 - 2 of 2) sorted by relevance
| /freebsd-9.3-release/share/mk/ | ||
| H A D | bsd.obj.mk | diff 99875 Fri Jul 12 13:09:35 MDT 2002 ru Moved the `distribute' target from bsd.obj.mk to bsd.subdir.mk, to make it call `install' in the bsd.subdir.mk-driven makefiles too. (share/examples/Makefile,v 1.29 changed the bsd.prog.mk to bsd.subdir.mk and many stuff was lost during "make release". I then merged this change in rev. 1.28.2.2 to work around the namespace pollution (FILES) in this makefile.) There was an added complexity here. Both the `distribute' and `install' targets are recursive (they propagate to SUBDIRs). So `distribute' first calls `install' in the ${.CURDIR}, then calls `distribute' in each SUBDIR, etc. The problem is that `install' (being also recursive) causes the stuff from SUBDIR to be installed twice, first time thru `install' in ${.CURDIR} triggered by `distribute', second time by `distribute' run in the SUBDIR. This problem is not new, but it became apparent only after I moved the `distribute' target from bsd.obj.mk to bsd.subdir.mk. My first attempt testing the fix failed due to this, because the whole world was distributed twice, causing all the imaginable mess (kerberos5 stuff was installed into both "base" and "krb5" dists, there was /sbin/init.bak, etc.) I say the problem is not new because bsd.prog.mk and bsd.lib.mk makefiles with SUBDIR (even without this fix) had this problem for years. Try e.g. running ``make distribute DISTDIR=/foo'' from usr.bin/bzip2 or from lib/libcom_err (without the fix) and watch the output. So the solution was to make `install' behave non-recursive when executed by `distribute'. My first attempt in passing SUBDIR= to the `install' in the `distribute' body failed because of the way how src/Makefile and src/Makefile.inc1 communicate with each other. SUBDIR='s assignment precedence on the "make install SUBDIR=" command line is lowered after src/Makefile wrapper calls "make ... -f ${.CURDIR}/Makefile.inc1 install" because SUBDIR= is moved into environment, and Makefile.inc1's assignments now take higher precedence. This may be fixed someday when we merge Makefile with Makefile.inc1. For now, this is implemented as a NO_SUBDIR knob. Spotted by: Dmitry Pryanishnikov <dmitry@atlantis.dp.ua> Prodded by: des MFC after: 3 days |
| H A D | bsd.subdir.mk | diff 99875 Fri Jul 12 13:09:35 MDT 2002 ru Moved the `distribute' target from bsd.obj.mk to bsd.subdir.mk, to make it call `install' in the bsd.subdir.mk-driven makefiles too. (share/examples/Makefile,v 1.29 changed the bsd.prog.mk to bsd.subdir.mk and many stuff was lost during "make release". I then merged this change in rev. 1.28.2.2 to work around the namespace pollution (FILES) in this makefile.) There was an added complexity here. Both the `distribute' and `install' targets are recursive (they propagate to SUBDIRs). So `distribute' first calls `install' in the ${.CURDIR}, then calls `distribute' in each SUBDIR, etc. The problem is that `install' (being also recursive) causes the stuff from SUBDIR to be installed twice, first time thru `install' in ${.CURDIR} triggered by `distribute', second time by `distribute' run in the SUBDIR. This problem is not new, but it became apparent only after I moved the `distribute' target from bsd.obj.mk to bsd.subdir.mk. My first attempt testing the fix failed due to this, because the whole world was distributed twice, causing all the imaginable mess (kerberos5 stuff was installed into both "base" and "krb5" dists, there was /sbin/init.bak, etc.) I say the problem is not new because bsd.prog.mk and bsd.lib.mk makefiles with SUBDIR (even without this fix) had this problem for years. Try e.g. running ``make distribute DISTDIR=/foo'' from usr.bin/bzip2 or from lib/libcom_err (without the fix) and watch the output. So the solution was to make `install' behave non-recursive when executed by `distribute'. My first attempt in passing SUBDIR= to the `install' in the `distribute' body failed because of the way how src/Makefile and src/Makefile.inc1 communicate with each other. SUBDIR='s assignment precedence on the "make install SUBDIR=" command line is lowered after src/Makefile wrapper calls "make ... -f ${.CURDIR}/Makefile.inc1 install" because SUBDIR= is moved into environment, and Makefile.inc1's assignments now take higher precedence. This may be fixed someday when we merge Makefile with Makefile.inc1. For now, this is implemented as a NO_SUBDIR knob. Spotted by: Dmitry Pryanishnikov <dmitry@atlantis.dp.ua> Prodded by: des MFC after: 3 days |
Completed in 41 milliseconds