| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Closes: #651748
|
|
|
|
These never worked out as well as I intended, and all indications
were that they would be a maintenance burden...or just bitrot.
Fully parallel builds are nice, but my builds are pretty quick on
my 8-core box even with the artificial chokepoints that automake
induces.
|
|
Hopefully this will eliminate some of the random crashes
on exit that people were seeing.
|
|
This seems to be the least worst option I can see. Since my Dist()
builder is outside scons and scons doesn't seem to offer any hooks or
listeners, I can't (safely) cause build files to always be added to the
distribution list. And anyway, I'm not sure I want to.
Better to make the distribution fully explicit.
|
|
Before this can work, I need to add all the SConscript files to the archive
explicitly, which is yucky.
|
|
I originally was going to have an "aptitude" target that builds aptitude,
but scons doesn't like having an alias that matches the basename of
a real target.
|
|
As opposed to automake, paths in scons *should* be relative for variant
builds (automake paths should *not* be relative for the same reason;
a bit confusing, eh?)
|
|
it needs from a sibling directory.
|
|
|
|
gtk still isn't built since I need to set up its build environment etc.
|
|
There are various problems with log4cxx, especially that it seems to be
unreliable and leads to random crashes. It might be a good idea to
eventually move to a different framework or roll our own. Decreasing
the number of explicit dependencies on log4cxx is a good way to do
that.
|
|
child being added or removed is false.
This is necessary, since (eg) adding a "false" value to an "and" can
change the value of the "and".
|
|
expressions that are always "true".
I considered trying to optimize by stripping NULLs out of "and" and
"or" expressions, but that seems a bit tricky. It might be more
straightforward if I introduce "true" and "false" expressions
explicitly, though (part of the trouble is that it's probably bad if
creation routines return NULL, and they can't currently return false).
|
|
I'm guessing that nothing was instantiating that method.
|
|
When I built a new validity expression as a result of combining
promotions, I forgot that expressions can be NULL and that NULL is
implicitly treated as a universally true expression. It might be
more robust to fully incorporate that into the API of the expressions
module at some point.
|
|
This was part of the initial design of the resolver, but it
turned out to be unnecessary in practice, and the problem it
tried to solve is actually quite difficult, so I never finished
the implementation.
|
|
underestimated because the "maximum" cost isn't actually maximal.
The algorithm that was at fault started with the highest possible cost
and incrementally lower-bounded it with the costs in the solver set,
to compute the lower-bound of the whole solver set.
That was the idea, anyway. It probably worked right when tiers had
exactly two elements and there was a sensibly-defined highest tier.
But now that means we start with
(MAX, 0, 0, ...)
and then lower-bound with, say,
(10, 1, 5, 4)
to get
(10, 0, 0, ...)
and, well, you see how that goes. The fix is a bit of a hack but will
do what I need here (producing a conflict if there are no solvers and
the lower-bound of all the solvers' costs otherwise).
|
|
solution deferred or discarded into helper functions.
The discard helper function existed already but wasn't being used
consistently.
In addition to making the code cleaner and more readable, this will
make it easier to enforce a "ceiling" on solution costs, discarding
solutions that go over the ceiling in one or more components.
|
|
The only remaining references to tiers are in backwards-compatibility
code; the "safety" cost component is composed of several "tiers" whose
values can be configured.
|
|
is based on "cost" instead.
|
|
Although the concept of a "tier" is useful (to distinguish changes
in the tier from the things being changed), the actual data type isn't
needed. We can just store an operation that computes the tier of a
step given a minimal tier.
Throwing out tier objects yields several benefits. It makes the code
somewhat simpler by reducing the number of complex object types
floating around. It will make it easier to clean up the nomenclature
by talking about costs instead of tiers. And it will make it easier
to impose a "cost ceiling", just by virtue of making the cost-tracking
subsystem simpler.
|
|
|
|
Not even compiled because I don't seem to have a full development
environment installed on this machine yet (oops).
|
|
cause a step to be discarded.
This is another part of the groundwork for more configurable solution
search criteria: the client of the resolver will be able to say that
steps in which particular tier components exceed a given level should
be discarded; consolidating all the ad-hoc tests into a single routine
is the first step to implementing that feature.
|
|
tier operations.
This didn't actually make it faster, but I think it does make things a bit clearer.
|
|
is above another tier without actually computing an intermediate value.
The tier operation code was the only thing that looked at all like a new
cost center in a profiling run (which makes sense since that's really
all that changed in the build that's slower). This might help a little;
the "take an upper bound and compare" trick is played a lot at the
moment.
|
|
It looks at a quick glance like I was wrong about the efficiency issues;
it may have just been due to comparing a non-optimized build to an
optimized build.
|
|
this is the first step towards being able to minimize the number of changes meeting a criterion.
The biggest change for this is that the new cost objects (tier operations)
are not totally ordered, so various places that used to take a maximum
now take a least-upper-bound instead; similarly for minimum and
greatest-lower-bound. Still to do: find a sound way to allow the resolver
to add together costs instead of upper-bounding them: "this change
will force us to remove 10 packages".
The new code seems to be a little too slow -- probably it lost some
optimizations by accident. It does seem to be correct, though.
|
|
user level with a negative index in a tier operation.
|
|
I wasn't incrementing the column index correctly, which resulted in
junk "nop" values being inserted into the serialization.
|
|
|
|
|
|
|
|
the initial broken set.
|
|
promotions in a step when we come back to it.
|
|
|
|
modifies a negative index in the user tiers array.
|
|
middle of the operation.
|
|
The rule in this system is that you can increase tier levels either
by adding positive numbers to them or by lower-bounding them. Any given
slot in the tier has to be managed using only one of these operations,
but different slots can be managed using different operations. This
allows support for the new "add to tier" operation, while maintaining
the ability to do the old "increase to level" operation (both for
backwards-compatibility and for supporting pin priorities).
Currently the unit tests fail; this needs to be fixed.
|
|
|
|
objects.
|
|
|
|
|
|
|
|
The comment at the top of tier_operation cheerily asserted that these
two operations formed a specific partial order. They don't. Each of
them *individually* does, but there is no natural ordering between
them: for instance, "increase to 100" takes 5 to 100 and 105 to 105;
"add 5" takes 5 to 10 and 105 to 110. Worse, they aren't closed under
composition, since order matters and it isn't stored in an operation
(and can't be without making operations contain a whole chain of
compositions).
The effect I was trying to get with increase-tier can be achieved,
albeit not in a backwards-compatible way, by adding levelwise upper
bounds to tier objects at a higher level (i.e., in the resolver).
The point here is to be able to have a tier that, for instance, is
0 if there are no removed packages and 1 if there are *any* removed
packages (i.e., it doesn't distinguish between different numbers of
removals in the same way that the current removal tier doesn't).
|
|
|
|
|
|
This needs a unit test and an operator<<.
|
