tech-toolchain archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Sets, subsets, syspkgs, and MK*
Date: Thu, 17 Dec 2009 03:05:26 +0900
From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
Message-ID: <091217030526.M0100026%mirage.ceres.dti.ne.jp@localhost>
| I'm asking if there is any objection against the words
| "MKfoo=no should not produce different binaries but should be subset"?
If you're asking if Masao Uebayashi agrees with that restatement,
then clearly I cannot comment.
If you're asking whether anyone would object to that, then yes, I would,
both because it doesn't provide what I really want, and because it doesn't
work anyway.
As you say ...
| USE_foo users can't use binary patches since they are custom binaries.
But MKfoo=no must imply USEfoo=no, surely - you cannot possibly be
planning on using something that you don't build.
The converse is not true, you can have USE_foo=no and MK_foo=yes (build
it, but don't use it) for whatever value that adds.
For the "not what I want" part, I want to really change what gets
linked into lic with USE_foo=no, so there is no possibility of foo
ever being accidentally used (and yes, no possibility of any binary
patch even allowing foo to be used.)
That is, I see three different setups:
foo is built, installed, and used
foo is built (by TNF perhaps) but not installed (and hence not used)
foo is not built at all (and even if built and installed later, never used).
Set (3) there is me. I don't see this to being a problem for binary
patches though, which are for people in the first two sets. Just forget
about anything related to how you deal with troglodytes like me, and
make it work for people who prefer using binary releases & updates.
Leave the MK* and USE* alone, and (where appropriate) just divide big
pieces of the system into smaller independently installable pieces,
that work it various odd combinations (and test all the possibilities.)
kre
- Prev by Date:
Re: Sets, subsets, syspkgs, and MK*
- Next by Date:
Re: Sets, subsets, syspkgs, and MK*
- Previous by Thread:
Re: Sets, subsets, syspkgs, and MK*
- Next by Thread:
Re: Sets, subsets, syspkgs, and MK*
- Indexes:
Home |
Main Index |
Thread Index |
Old Index