| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
|
|
As a side effect, this creates a "controllers" directory in the generic tree,
and removes the now-empty GTK+-specific controller and view directories.
The README files are moved over to the generic locations and tweaked to be
correct for their new home.
|
|
|
|
|
|
|
|
implementation for showing the download progress at the command line and a stub implementation.
This is mostly just a streamlining of the apt interface, but putting the
code behind a clean view will also make it much more testable.
|
|
separate file to reduce test dependencies.
No reason for tests to pull in half of src/generic/apt just because a module
linked into the test happens to reference a global pointer.
|
|
|
|
|
|
One of the tests fails, and it appears to be a legitimate failure.
|
|
the effect of a sequence of outputs on a normal terminal.
|
|
terminal output.
The extra logic is to avoid having tests that depend on exactly how the code
being tested breaks up its terminal writes.
|
|
Hopefully this will eliminate some of the random crashes
on exit that people were seeing.
|
|
the logging tests to it.
gtest has some nice features for producing extra information in failures
that could be handy. Also, it integrates well with gmock; the gmock
failures in my Boost tests were sometimes kind of obscure.
|
|
|
|
I use google-mock to create a mock implementation of the view, then
test that the logic interacts with it as expected. Right now, it
doesn't.
The ability to do this was part of why I wanted to separate the logic
from the view.
I haven't added google-mock to configure.ac yet; need to do that later.
|
|
I think this is actually the abstraction I want for the toplevel UI;
order should be determined by the view, not hacked into the container
layer.
|
|
|
|
|
|
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.
|
|
directory.
This is IMO a better idiom than adding a dummy dependency, since it
will continue to work even when/if I disable the duplication of the
source tree into the build directory.
|
|
caches.
I could have just used the version in the source directory, but I like
using a copy in case anything goes wrong.
|
|
This variable is badly conceived. The test should just expect a
variable giving the absolute path to the test data. Instead, it wants a
path to the parent of the test data, relative to the dirname of argv[0].
|
|
executed.
|
|
|
|
|
|
Doesn't actually work since scons doesn't escape command-line arguments,
so the shell eats the quotes.
|
|
It ends up depending on a lot of the source code, but this has some good
effects: first, the test won't be rebuilt unless its actual dependencies
change; second, the test will be rebuilt when its actual dependencies
change; third, it makes it explicit exactly what the tests need for a
human reader.
|
|
A dict apparently can't be appended, but a tuple (var, value) works.
|
|
Apparently scons is happy to depend on the output of another environment;
the problem was that I was implicitly defining a second build rule for
the .o in a new environment.
|
|
This causes a problem (currently nonfatal but should be fixed), because
scons doesn't like that I ask for some .cc files with "different"
environments. Need to look into how best to fix this.
|
|
|
|
TODO: probably should add a UnitTest builder.
|
