On Tue, 2011-09-13 at 16:20 -0400, Stephen Smalley wrote: > On Tue, 2011-09-13 at 22:04 +0200, Guido Trentalancia wrote: > > It is up to the maintainer to keep the SUBDIRS variable ordered > > (according to the dependency relations). > > > > See for example: > > > > http://www.gnu.org/s/hello/manual/make/Phony-Targets.html#Phony-Targets > > http://www.gnu.org/s/hello/manual/automake/Subdirectories.html > > Ok, we have ordered SUBDIRS in the Makefile in such a manner that each > component is built before anything that depends on it. Yes, the order looks fine to me. Could upgrade to phony targets as well (see first document). It would allow parallel builds and also it would prevent it from continuing on failure of a target. > > > In your case, the sepol headers should have > > > already been installed before trying to build libselinux, and I don't > > > know why that didn't happen for you unless your make reorders SUBDIRS > > > internally or the make install in libsepol failed to complete (but I > > > wouldn't expect it to proceed in that case). > > > > The make tool should not reorder variables in any case. > > Good. > > > I did not issue a "make install" (yet). I did just issue "make" from the > > top-level directory. > > Right, that can't work and never has, which is why 'make' used to invoke > 'make install' until Eric (incorrectly) changed that behavior. "make" should never invoke "make install". It is not desirable that an installation takes place without the user *explictly* requiring it. However that behavior should be changed for many other reasons, including in particular the possible security risk associated with static linkage of an old libsepol.a. > > I am not building the components separately, I am building the whole > > bundle (tools + libraries) from the top-level directory of the git > > version. That's the point. > > Understood, and the only way to do that has always been make > DESTDIR=~/out. Reverting/fixing the changes that have broken that > behavior is the right solution. See above and also see latest reply from Eric. > Looking at your last patch, I don't see how it can possibly work in the > case where one isn't building the entire source tree (e.g. for package > building), because it encodes a relative path to the static libs in > LDLIBS. If it accidently ends up in the separate packages, it still won't affect their build, because the compiler include/link flag would fall back to the system-wide files. However, ideally, part of the patch should be reverted prior to creating the release archives for the separate components. As it is, the patch is intended for the whole git bundle (top-level pull). Regards, Guido -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
