Re: [PATCH v2] build: Option for building all tools in a single binary

[Alex Deymo]

Hi!
I'm back.

On Mon, Jul 7, 2014 at 8:40 AM, Pádraig Brady <address@hidden> wrote:

> On 07/07/2014 12:41 AM, Bernhard Voelker wrote:
> > On 07/05/2014 03:40 PM, Pádraig Brady wrote:
> >
> > 15. src/coreutils-{arch,dir,vdir}.c wrapper:
> > Why don't we do this also in non-single-binary case? ;-)
>
> leaving as is for now
>

Doing this in the non-single-binary case doesn't help much. In the current
code, these three binaries differ only in the value of a variable in the
.data section. Using the single-binary code, they would differ is some code
that runs and sets that value accordingly.


Changes are attached to this email.
>
> Rolled up patch is at:
> http://www.pixelbeat.org/cu/single-binary_v9.patch
>
> One other change to consider is that we might
> change `coreutils --coreutils-prog=` to `coreutils --program`
> as the former is a bit long/awkward/redundant?
>

The idea of the awkward/redundant flag is that it is unique. The current
coreutils.c checks both the argv[0] and the --coreutils-prog= flag as
argv[1]. The flag is only used internally and users should not pass that
flag to any other program, so the code works either for symlinks o
shebangs. If you want to change the flag to something shorter like
"--program" then we should also pass a compile-time value to coreutils.c to
tell it where to read the program name from (argv[0] basename or a suffix
of argv[1])

Another thing I just thought of is that we should change the ENOENT
> warning in coreutils.c to something explicit as the error
> pertains to internal functionality, rather than optional
> external links/scripts etc.
>

Let me know if you want me to work on these changes (or other) so we don't
duplicate the work.
Thanks,
deymo.