[Swan-dev] what should "make ; sudo make install" do (again)

[Andrew Cagney]

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 <paul at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20150522/f406f3c6/attachment.html>