[haiku-commits] Re: haiku: hrev46201 - build/jam src/system/libroot build/jam/images

  • From: François Revol <revol@xxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Thu, 10 Oct 2013 00:43:57 +0200

On 09/10/2013 23:43, Ingo Weinhold wrote:
> On 10/09/2013 10:11 PM, revol@xxxxxxx wrote:
>> d6de84d: Allow stripping binaries when copying to image containers
>>    Currently only needed for boot floppy on some platforms.
>>    Disabled for now.
>>    Note we do not have a mean of knowing which file is a binary
>>    or not so we just try to strip, and silently continue when
>>    strip fails (like on the kernel settings file).
>>    Also note strip actually replaces the file, which means it looses
>>    both the resources and attributes, which shouldn't be a problem
>>    for the boot floppy drivers archive, but is not wanted for other
>>    images, so it's not usable elsewhere as such. Patch wanted.
> Please revert. It cannot work this way, since strip cannot operate on
> files in the image (unless you intend to add a strip command to the FS
> shell). I would rather add the option of stripping to the Link rule,
> which would also avoid the resources issue.

Well it wouldn't work in the image anyway since it doesn't preserve
attributes and resources.

I chose not to do it in the Link rule because I wanted to keep the
unstripped binaries around for things like gdb to use...
which wouldn't be the case anymore.

> Alternatively a rule that makes a copy of a file and strips that copy
> (while preserving respectively re-adding resources and attributes
> (copyattr + xres)) could be implemented. That would also easily allow
> adding a stripped version of the file to the boot floppy and an
> unstripped version to the image.

That could be done, actually strip has a -o option so it would avoid
wasting a copy operation. But I didn't need that for the boot floppy and
I wanted to fix building on all platforms first, without having to dig
all the different use cases to make sure I could always use copyattr.

And I still need to properly enable it only for m68k.
ArchitectureRules is included before BuildSetup but the case with other
floppy variables is in a rule invoked after BuildSetup sets vars on the
floppy container target, so it won't be as clean as I thought.


Other related posts: