Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cgwalters The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
(There's a lot of other cruft around documentation and the move to cosa that I didn't try to address here) |
|
Hmm, let's back up a bit here. Here's how I see the build system integrating with cosa:
So in that picture, Another way to say this is, I agree we want to make More concretely, |
Yes...but then it goes off and does a whole lot of other stuff unrelated to that. Bigger picture I think the way I'd like to see things go is more that cosa drives things rather than each project scripting cosa. For example, this would enforce more uniformity among projects and also make it more straightforward to build/test multiple projects simultaneously. It'd also paves the way for having rpm-ostree's test suite tests run indepenenently of building it. |
|
A good hint of how hacky things here are is that running |
|
IOW, we're not actually really using |
Using `make` as an entrypoint works best when the extended target needs to interact somehow with building the software. We need `make check` to be a target becuase it actually does build code. But for `vmcheck` that's not true. And in particular using `make` targets is awkward when one wants to configure/shortcut what the target is doing, as we have with the environment variables `SKIP_VMOVERLAY` etc. I think it's just cleaner and more obvious to have a script to execute - and this script can have command line arguments. All this does is remove the `make vmcheck` wrapper, but I want to rewrite the entrypoint script to have e.g. `./tests/vmcheck -O` where `-O` means "skip overlay".
d412873 to
aa4302b
Compare
That's already the case today. (Part of #1949 was doing this decoupling so that CI didn't have to build the tree first).
Again, the idea with If you're using
I see where you're coming from, though I think there's also a lot of value in not having to context switch between working directories and tools when hacking. If I'm trying to get a test working, I want to be able to just hack on the rpm-ostree source code/tests, then immediately Anyway, I'm not opposed to trying this out. I think time will tell where the pain points are as cosa and workflows mature. In that case though, there's really no point in having |
|
Closing in favor of momentum in #2072 |
Using
makeas an entrypoint works best when the extended targetneeds to interact somehow with building the software.
We need
make checkto be a target becuase it actually doesbuild code.
But for
vmcheckthat's not true. And in particular usingmaketargets is awkward when one wantsto configure/shortcut what the target is doing, as we have with
the environment variables
SKIP_VMOVERLAYetc.I think it's just cleaner and more obvious to have a script to
execute - and this script can have command line arguments.
All this does is remove the
make vmcheckwrapper, but Iwant to rewrite the entrypoint script to have e.g.
./tests/vmcheck -Owhere-Omeans "skip overlay".