[Toybox] Out of tree build support

[Patrick Oppenlander]

On 20/12/17 09:24, Rob Landley wrote:

> Really what I need to do is come up with a way to build toybox sed and
> toysh standalone from a canned script with no config step, and then
> build the rest with that.

Makes sense.

> Speaking of which, did I ever point you at the cp -s trick?
> 
>    $ cp -rs "$PWD"/toybox walrus
>    $ cd walrus
>    $ make distclean && make defconfig && make
> 
> (I taught toybox to work with relative rather than absolute paths. The
> gnu/dammit version complains about relative paths, and yes that means
> even "cp -rs toybox walrus" won't work unless you're using toybox cp.
> It's because they don't bother to calculate the dynamic ../ stack.)

That is a neat trick. First time I've seen it, thanks!

> One of my todo items is writing a new kconfig to replace the kernel
> plumbing I borrowed way back when. (Which is from 2.6.12.)

Even before that the issue is that there's no way to build kconfig from a script, so the *config targets depend on make.

>> I've pushed the current state of affairs to
>> https://github.com/pattop/toybox if you're interested in taking a look.
> 
> Hmmmm... I see what you're doing, but you're adding complexity to the
> Makefile and I want to strip it out and move it into the scripts.

I think the changes to the top level Makefile aren't too bad. They really just boil down to teaching make where to find sources & scripts by sprinkling in a few $(SRCDIR)s and don't change any of the logic at all.

kconfig/Makefile probably needs to be replaced by a script so the hackery in there is fairly moot. Would you be interested in a script that replaces this?

Are you happy with the direction of the changes to the scripts in general?

It might be worth considering passing $(MAKECMDGOALS) to make.sh (or a higher level driver script) at some point. It could then call single.sh or test.sh and eliminate the requirement for .singlemake. You could then call make.sh from a catch all rule in the top level makefile and really turn the makefile into a trivial wrapper.

>> The symlinks in kconfig are a bit nasty (they really should go in the
>> build directory to avoid polluting the source dir, but as they're always
>> the same...). I got this working with vpaths earlier but wasn't too
>> thrilled with the result.

What's the reason for the symlinks in kconfig anyway? I had a quick look through the history and couldn't find anything obvious.

>> CC'ing you as I don't seem to be getting list emails at the moment.
> 
> I seem to be, but I think I've been cc'd on everything the past couple
> days anyway?

I'm not receiving emails for this thread. Maybe the mailing list is smart enough to know you're CC'ing me?

Patrick