-
Notifications
You must be signed in to change notification settings - Fork 233
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hooks are tied to build platform #723
Comments
I think adding a complete new build system like that would lead to some serious over-engineering. Using local script tools seems like a reasonable approach IMHO. I do see the benefit of trunks approach for sure. But you could also leverage that for exactly this scenario using the |
The idea is indeed interesting. One thing is a bit tricky however: what I'm after for my app is getting files copied only when a specific feature is requested (the nominal app make fetches from remote URLs, the My original approach approach was to let Sure, I can keep the same
So could we make it possible to move all this logic into an xtask, conditioned to a feature? For the xtask to know about the feature, it would be given to
What do you think? |
I am wondering why you don't just use an env-var for this? You can easily check that in an xtask for example. |
Moving the |
Well as |
I thought about that (that's the "So could we make it possible to move all this logic into an xtask, conditioned to a feature?" in this post), but it would still require support from Trunk to pass this flag only in certain conditions. |
I am sorry, I don't understand why? |
Instead of a 2-step copy, first done by build.rs, then from there by the post_build hook, get the hook to copy directly into trunk staging dir. Ought to be easier to maintain by having all that code in a single place. This moves the dependency on the data crate from a build.rs dep to an xtask one. FIXME: - cannot condition this with the feature any more, has to pull the dependency on the data crate even when feature is disabled - duplicates opr-rs rev in 2 Cargo.toml files See trunk-rs/trunk#723
I meant, if I have 2 different xtasks, for feature-on and feature-off, the problem is now "how do I select which xtask to run?". I still fail to see what your idea is to achieve this. As a concrete basis for discussion, my initial attempt at moving everything in one step can be found in ydirson/generals-familiar#33 |
Hm ok, maybe you can create a small example repository to illustrate the problem. |
I created an example project for experimenting with hooks: https://github.com/trunk-rs/trunk/tree/main/examples/hooks This has one xtask based hook. And another approach of using the |
Provided hook examples clearly show how platform-dependent they are: if I use a
cp
to copy additional data in apost_build
hook (generated data that cannot be found by<link data-trunk rel="copy-dir" ...
), it is working all right on my Linux dev box, but will break on any Windows dev trying to build my app.Traditionally Cargo has been avoiding this by letting the crate author specify additional build commands in Rust (
build.rs
). It does not look trivial for the author to write a separate hook script in Rust and get it built for the build architecture, though sorting out how to do that and providing an example could be a first step. Then transparent support in trunk for eg.trunk_hook_post_build.rs
and such would be a way to make this easily available to crate authors.As an alternative, hooks as they stand now should make it possible to declare using
cfg
-like architecture expressions that a hook is specific to certain build architectures, provide a way to specify implementations for other platforms, and bomb out with "unsupported build platform, please patchTrunk.toml
". But while that looks like a more natural evolution, it is IMHO not trivial enough given the value it provides.The text was updated successfully, but these errors were encountered: