RFC: cross-building crda

RFC: cross-building crda

[Jon Loeliger]

John,

I'd like to propose a few changes to the CRDA Makefile
to allow better cross compilation support, and would
like to get your suggestion/approval/recommendation on
an overall approach before I get to far into it.

First, the easy change would be to allow some local
customization by adding "-include .config" as the first
line of the Makefile in the same style as the iw Makefile.

Second, in CRDA's Makefile, the "verify" step that builds
and uses regdbdump is really a host build and operation.
The regdbdump tool might then also be (re-)built as a target
tool and installed on the target as well.

So I'm proposing to introduce a two-layer build where the
top-level Makefile will introduce a "host/" and a "target/"
sub-directory build for each environment.  If the build
is not a cross-build, no "target/" build happens and it
all gets built in "host/" only.  The C files and sources
all stay in the current top-level directory, and will be
referenced and built into the host/ and target/ through
Makefile fidgery sub-directories.

Things like the CFLAGS and LDLIBS will have dual host
and target specific variants built-up and used in their
respective sub-driectories, all driven by the top-level
Makefile still.

Stylistically, would folks prefer
    1) three separate Makefiles in the top-, host/ and
       target/ directories, non-inclusively doing sub-make
       requests (ie, "make -C host/ all"),
    2) three Makefile components that all get "included"
       into the top-level Makefile without doing sub-make
       build requests,
or
    3) Just one top-level Makefile that hard-codes and
       builds targets directly into the sub-dirs?

Thoughts?

Thanks,
jdl

Re: RFC: cross-building crda

[Pavel Roskin]

On Thu, 2009-06-11 at 10:21 -0500, Jon Loeliger wrote:

> So I'm proposing to introduce a two-layer build where the
> top-level Makefile will introduce a "host/" and a "target/"
> sub-directory build for each environment.  If the build
> is not a cross-build, no "target/" build happens and it
> all gets built in "host/" only.  The C files and sources
> all stay in the current top-level directory, and will be
> referenced and built into the host/ and target/ through
> Makefile fidgery sub-directories.

This sounds too complicated.  No other popular software does it, yet
somehow it can be cross-compiled.  I'm not talking about such software
as kernels, compilers and other tools that need to know specific
characteristics of the target.

Please check the sources of buildroot (http://buildroot.uclibc.org/) to
see how it manages to cross-compile a lot of programs that don't do
anything specific to support cross-compilation.  Sometimes minimal
patches are needed, but nothing nearly as intrusive as your proposal.

-- 
Regards,
Pavel Roskin

Re: RFC: cross-building crda

[Jon Loeliger]

On Thu, 2009-06-11 at 18:51 -0400, Pavel Roskin wrote:
> This sounds too complicated.

Hi Pavel,

Thanks for your feedback.

>   No other popular software does it,

That's just flat not true.  Even Linux itself separates the
components that need to be built for the host from those that
need to be built for the target machine.  The Kconfig, dtc and
other tools in the scripts directory, for example, are host
tools are built and used during the rest of the target build.

>  yet
> somehow it can be cross-compiled.  I'm not talking about such software
> as kernels, compilers and other tools that need to know specific
> characteristics of the target.

Thanks, I get that.

> Please check the sources of buildroot (http://buildroot.uclibc.org/) to

And that.  Really, I get the whole cross compile thing.
And its environment.  Mine happens to be LTIB for PowerPC
and I'm using a powerpc-e300-linux-gnu- toolchain to do so.

> see how it manages to cross-compile a lot of programs that don't do
> anything specific to support cross-compilation.

The bulk of the CRDA correctly cross compiles by simply using
and setting CC to allow for CROSS_COMPILE like this:

    CC := $(CROSS_COMPILE)gcc

That's not the problem.

>   Sometimes minimal
> patches are needed, but nothing nearly as intrusive as your proposal.

The build of regdbdump needs to be split out as a *host* tool.
It is used on the *host* to verify the regulatory.bin database.
It shouldn't need, nor does it use, for example, the libnl that
is currently supplied on the link line for that executable.
That libnl is the *target*'s library for target linking.

Furthermore, this same distinction applies to the grcypt/openssl
library that is selected.  In fact, if regdump is built once
for the host and once for the target, you may need different
crypto mechanism selections for each.

You can see the same distinction in kconfig's Makefile where it
says this around line 95:

    96  # Use recursively expanded variables so we do not call gcc unless
    97  # we really need to do so. (Do not call gcc as part of make mrproper)
    98  HOST_EXTRACFLAGS = $(shell $(CONFIG_SHELL) $(check-lxdialog) -ccflags)
    99  HOST_LOADLIBES   = $(shell $(CONFIG_SHELL) $(check-lxdialog) -ldflags $(HOSTCC))
   100  
   101  HOST_EXTRACFLAGS += -DLOCALE

All I'm doing is the same HOST tool separation for CRDA.

RFC patch for comments to follow.

Thanks,
jdl