Ok, I'm just pushing an update so that: - "make base install-base list-base clean-base" builds; installs; lists the files of; and then (not really tested) cleans a "base system build", what ever "base system" means. I suspect that some of the top-level makefile targets, such as "make ipkg", could be tweaked to use these new targets
- swan-build and swan-install use "make build" et.al. which roughly halves the build time - "make all install install_file_list clean" builds, installs, lists, cleans a full "userland" build - "make" from the top level prints To build and install on a recent Linux kernel that has NETKEY: make all && sudo make install For a minimal install (no manpages) type: make base && sudo make install-base See the files INSTALL and README for more general information, and details on how to build / install on KLIPS and other systems - "make" in sub-directories defaults to "all" (this was already mostly the case) - "make manpages install-manpages list-manpages clean-manpages" does just man pages - "make module" et.al. as before - the target that shall not be named is an alias for "make all" In addition, as yet another reminder of why "recursive make is evil", I've also fixed a bug where parallel make could end up running two make processes in the same directory :-/ Andrew On 15 May 2015 at 13:35, Paul Wouters <p...@nohats.ca> wrote: > On Fri, 15 May 2015, Andrew Cagney wrote: > > My suggestion here is to remove "programs" from any and all >> documentation; but accept it as an >> undocumented alias for building all of userland including manuals. >> > > That's fine with me. > > I personally think "all" should build modules as well; but that seems to >> get messy. The argument for >> not having "make" default to building everything including modules is >> that the user needs to select >> which modules to build; hence "make" prints a help message and lets the >> user decide. >> > > I don't think so. For one, "module" is a target only on Linux, not on > any other OS we build on. Second, most people at this point should not > build KLIPS and use the stock NETKEY/XFRM code. So 95% of people have > no need for "make module". For the fedora, rhel and debian packages, > no KLIPS is shipped so we can/should not compile it there. > > The other complication is that we need some short cuts (aka targets) to: >> >> - build/install all but documentation - linux cross compiles apparently >> can't deal with documentation >> > > You had sort of convinced me those days are over. I also noticed xmlto > no longer drags in latex for me, so perhaps this requirement is now > fine. The only issue is that I would like the test VMs to be able to > not unconditionally rebuild these, beause xmlto is quite slow and it > really slows down the compile/install/test cycle. > > - build/install just binaries and scripts - to speed up test builds (this >> one would be less of an >> issue if the test-build process didn't rm -rf OBJDIR) >> > > If we are getting confident that dependancies in lib/ are now properly > detected, and make will rebuild it all fine, the rm -rf could go :) > > Paul >
_______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
