[racket-dev] Compiling tests
On Fri, Mar 30, 2012 at 10:02 AM, Eli Barzilay <eli at barzilay.org> wrote:
> Yesterday, Robby Findler wrote:
>> This has caused me some trouble and I'm not sure it is a good way to
>> go, in general. Specifically, I'd like to think that our newer tests
>> will more and more be things we'd want to compile.
>>
>> My desire to compile the tests is the same reason I want to compile
>> any Racket file: so it loads faster.
>
> (To be clear, you're not talking about any other benefits besides
> being able to run your tests faster, right? Since drdr (or the
> nightly build, for those tests) will still run them and report.)
I find it valuable to work with compiled racket files when I build
racket software, tests or not. The drracket tests, in particular, have
non-trivial libraries that go with them, more than just a sequences of
inputs and outputs.
> This sounds like a very minor damage: it's only you who wants to run
> your tests, and even that happens only when you're testing... It
> seems that the benefit is also a minor improvement in tree setup
> speed, but that one is done much more frequently, and by much more
> people, so we get: minor ⋘ minor * much². Even more: I think that in
> all cases that I ran test code, it happens while I'm editing the code
> that is tested and/or the tests -- so I don't even get that small
> benefit in my workflow.
I thought you said that disabling the eopl tests gets most of that
benefit. Assuming that was right, I would prefer to do that (this is
what I was trying to say in my previous message).
> In any case, I have no principle objection here... For the nightly
> build (and for my own builds), I can easily just hack it to add the
> `compile-omit-paths' definition before it builds the tree -- but given
> the above, I think that most people would prefer to enjoy the shorter
> build times. (Kind of obvious when most people don't run these tests
> on a regular basis.) If not, I'll do that hack.
>
> Alternatively, add a flag to setup that is similar to `-D' to omit
> compiling tests (and have it on by default).
>
>
>> So, I'd like to go back to the old way: I can try disabling eopl
>> tests and look at any other problematic collections if that would
>> help with your original concern in a different way.
>
> [The problem with that approach is that new collections are being
> added when nobody's looking, and having no global `compile-omit-paths'
> means that they get compiled by default. So I'd rather go with the
> above hack than go back to selective exclusions.]
I'm fine with the nightly-build-based hack, but would prefer not to go
with a new "-D"-like flag -- not sure which of those you're referring
to here.
Robby