✨ Add the ability to build an entire workspace or a specific executable

[samuelsleight]

This PR adds a BinTestBuilder struct, which can be used to add the --workspace flag to cargo build and/or to build a specific executable with the --bin flag.

This was all fine for my specific use-case, but I'm very open to suggestions or alternative API ideas - if we're happy with this though, we could also use it to handle the RELEASE_BUILD flag too, though I wouldn't necessarily do that as part of this PR

[cehteh]

looks good on a first glance. I am out of office, will come back on this next days.

[samuelsleight]

All good, no hurry over the holiday period!
I'll be out myself for the first two of weeks of Jan, too, so this might end up waiting until the second half of the month if there's any discussion on it

[samuelsleight]

Okay, I squeezed one extra flag into this that I wanted, hopefully that's not too controversial! I should be 100% done with this branch now, as I'm happy with my test workflow where I'm using this

[cehteh]

I created a new 'devel' branch, updated the crate there (msrv, edition, metadata and other bits) and merged this PR. Please test and tell me your opinions.

This will be the base of a 1.1.0-devel release I can do sometime soon, then your rust code using bintest can depend on that.

I did a small change: the builder is now available over the BinTest::with() Api, thus only BinTest has to be imported by a user.

In future we can add more flags to the builder.

Another observation: we could now have a small workspace in this crate creating a binary which is used to test this crate itself :)

[samuelsleight]

Cheers, will check out that branch now and give it a test! The small change certainly seems nicer, keeping the needed imports minimal 👍

[samuelsleight]

@cehteh Yep, that's working nicely for me, and I definitely prefer the new API - I'm not 100% sure the name with() is perfect, but I can't think of a better name for it so I'm pretty sure it's fine as-is.

This PR shows the change (and my usecase) if you're curious. (...though something unrelated appears to have broken the CI)

Another observation: we could now have a small workspace in this crate creating a binary which is used to test this crate itself :)

Also I just spotted this line - that seems like a very nifty idea!

[cehteh]

@cehteh Yep, that's working nicely for me, and I definitely prefer the new API - I'm not 100% sure the name with() is perfect, but I can't think of a better name for it so I'm pretty sure it's fine as-is.

Same here, i am open for better name suggestions. I use this 'hidden builder pattern' or how its named frequently but i havent settled on good names yet, sometimes I use 'Foo::build().with_option().with_another_option().finish()' but i am not satisfied with that either.

[samuelsleight]

Maybe with is actually alright if the builder methods are sensibly named - then it reads like a Bintest "with" a list of options, which seems decent enough

[samuelsleight]

@cehteh What's your plan for a new published release? I've been pointing at the devel for a while now and it's been working perfectly for me after a small change in my own code to lazily run it once instead of running it in parallel which may be worth recommending - I'd now be happy to point this at a crates.io release if/when that's available!

[cehteh]

@cehteh What's your plan for a new published release? I've been pointing at the devel for a while now and it's been working perfectly for me after a small change in my own code to lazily run it once instead of running it in parallel which may be worth recommending - I'd now be happy to point this at a crates.io release if/when that's available!

When you like a stable release ASAP then I can do it. In some older codebase I use lazy_static! similar to how you using the newer Lazy. Which makes me think:

• This should be documented at least
• Perhaps the Lazy method should become part of bintest
  • either as breaking API change making BinTest a singleton
  • or by some optional API

So when you don't need it ASAP give me a few day and/or comment on the Lazy idea

[samuelsleight]

When you like a stable release ASAP then I can do it. In some older codebase I use lazy_static! similar to how you using the newer Lazy. Which makes me think:

* This should be documented at least

* Perhaps the Lazy method should become part of bintest
  
  * either as breaking API change making BinTest a singleton
  * or by some optional API

So when you don't need it ASAP give me a few day and/or comment on the Lazy idea

Yeah, fair enough - there's no hurry at all really, this is just a personal project so theres's no reall ASAP, it would just be nice if I could remove as many of my git dependencies as I can at some point.

I can file an issue recommending the Lazy pattern, and we can discuss there at some point whether it should be part of the library or documented as a recommendation