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

[Pádraig Brady]

On 07/08/2014 04:23 AM, Alex Deymo wrote:
> Hi!
> I'm back.
> 
> On Mon, Jul 7, 2014 at 8:40 AM, Pádraig Brady <address@hidden 
> <mailto: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.

If you could look at it it would be great thanks.
There's the above --coreutils-prog possible adjustment and the
man page issues Bernhard mentioned.

Re the --coreutils-prog adjustment, if we were adding a compile time adjustment,
then it might be possible to do away with an option altogether. i.e. support:

  coreutils ls ...

I'm not pushed either way TBH as I mainly see the explicit coreutils
invocation as a means to support the shebangs method.

thanks,
Pádraig.