ObsoleteFiles and TARGET_ARCH

[Alexander Leidinger]

Quoting "M. Warner Losh" <imp at bsdimp.com> (from Wed, 07 Jul 2010  
08:42:13 -0600 (MDT)):

> In message: <20100707145634.13925yt8ztdkz4is at webmail.leidinger.net>
>             Alexander Leidinger <Alexander at leidinger.net> writes:
> : Quoting "M. Warner Losh" <imp at bsdimp.com> (from Tue, 06 Jul 2010
> : 17:49:19 -0600 (MDT)):
> :
> : > I'm wondering...
> : >
> : > Why do we use TARGET_ARCH so much inside of ObsoleteFiles?  It seems
> : > like it should be used only when we obsolete files on some
> : > architectures, but retain them on others.  Instead, it seems to be
> : > used to obsolete files that normally exist on a specific
> : > architecture.  This seems backwards.
> :
> : As the person who wrote this initially:
> :
> : The goal was to only delete stuff which was not available anymore on
> : one architecture but where still available on others (as in the
> : 20040130 entry, IIRC at this time the rename was specific to sparc64
> : and other architectures still had this lib). If it is not used like
> : this, it is a bug.
>
> Then we have a lot of bugs.  About 45 of the 49 instances are
> definitely wrong from my quick inspection.

If those 45 instances are covering just one or two files, I agree. If  
those instances cover a huge number of files, it should be  
investigated if it makes a speed difference on architectures where  
those files never where. I do not expect it would make a significant  
speed difference in this case, but as I haven't measured it...

> : > Also, we need to change this, but I don't (yet) define a
> : > TARGET_CPUARCH.
> : >
> : > Also, why is this TARGET_ARCH and not MACHINE_ARCH?  That suggests
> : > we're invoking it wrong if this is "needed" for the cross build case
> : > to "work".
> :
> : The goal was to have something which can be used like "make
> : DESTDIR=/... XXX=arch_of_dest delete-old" where DESTDIR is either a
> : remote FS for a system of architecture as specified by XXX, or a local
> : mount of something with the same properties like in the remote FS
> : case. Without the XXX on the command line it shall behave like the
> : architecture is the same as the current system. If TARGET_ARCH is not
> : the correct XXX in the sense as described before, feel free to change
> : it to something better. I think I used TARGET_ARCH after looking at
> : what make universe is/was doing.
>
> The TARGET_ARCH=foo on the command line is correct.  However, the
> environment that these commands operate in should be the target one,
> not the host one.  ru@ appears to have changed MACHINE_ARCH to

I'm not sure I understand what you want to tell (due to lack of enough  
knowledge what those *_ARCH are supposed to do). As long as your  
description matches the following use case, I'm ok with any change you  
want to make in this regard:

Assume your system is running with an amd64 world and kernel, and you  
have a world for FOO128 available at /import/foobar which is at the  
same revision than what you have in /usr/src. You want to run "make  
DESTDIR=/import/foobar XXX=FOO128 delete-old" to delete the old files  
for FOO128 in /import/foobar.

Bye,
Alexander.

> TARGET_ARCH to, according to the comments, work in a cross-build
> world.  However, I think he fixed that bug incorrectly, so I'll try to
> fix it properly as part of my general cleanup of TARGET_ARCH abuses in
> the tree.
>
> Warner
>
>



-- 
First law of debate:
	Never argue with a fool.  People might not know the difference.

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137