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

[Pádraig Brady]

On 07/08/2014 11:50 AM, Pádraig Brady wrote:
> 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.

I'm itching to get coreutils-8.23 released, so completed the attached few final 
fixes.
I didn't think this would impact significantly any further worth you might be 
doing.

Here is the complete rolled up patch, which I'm about ready to push.
http://www.pixelbeat.org/cu/single-binary_v10.patch

thanks,
Pádraig.

multicall-v10-fixes.patch
Description: Text Data