g...
8. `make check master_tests` // compile and test
`src/tests/master_tests.cpp`
9. alright, looks good. `make check`
I have 0 attachment to the `make check master_tests` syntax. It'll be a
different syntax for CMake anyways. I just think that the ability to
perform separate compi
ster_tests` // compile and test
>`src/tests/master_tests.cpp`
>9. alright, looks good. `make check`
>
> I have 0 attachment to the `make check master_tests` syntax. It'll be a
> different syntax for CMake anyways. I just think that the ability to
> perform sepa
.cpp`
> >5. change some stuff...
> >6. `make check master_tests` // compile and test
> >`src/tests/master_tests.cpp`
> >7. debug...
> >8. `make check master_tests` // compile and test
> >`src/tests/master_tests.cpp`
> >9. alright,
gt; >`src/tests/master_tests.cpp`
> > >3. fix compilation errors...
> > >4. `make check master_tests` // compile and test
> > >`src/tests/master_tests.cpp`
> > >5. change some stuff...
> > > 6. `make check master_tests`
sts.cpp`
> 9. alright, looks good. `make check`
>
> I have 0 attachment to the `make check master_tests` syntax. It'll be a
> different syntax for CMake anyways. I just think that the ability to
> perform separate compilation of tests will be immensely useful.
>
> Some n
Hi,
being able to iterate more rapidly on tests sounds great.
I am slightly unsure about the cost of (i) linking even more binaries, and (ii)
the overhead of setting up the test environment for the invocations of test
binaries (I believe this was O(100ms) per `main` at some point).
I believe if
r_tests` // compile and test
> > `src/tests/master_tests.cpp`
> > 7. debug...
> > 8. `make check master_tests` // compile and test
> > `src/tests/master_tests.cpp`
> > 9. alright, looks good. `make check`
> >
> > I have 0 attachment to the `mak
t; 2. `make check master_tests` // compile and test
> > > `src/tests/master_tests.cpp`
> > > 3. fix compilation errors...
> > > 4. `make check master_tests` // compile and test
> > > `src/tests/master_tests.cpp`
> > > 5. change some stuff...
you're working in a very isolated part of the
> > codebase,
> > > > but it gets to be pretty bad if you're experimenting with parts that
> > are
> > > > widely used.
> > > >
> > > > An example of a workflow I'm aiming for would look
