run: allow suricatasc to be specified with an environment var - #3294
run: allow suricatasc to be specified with an environment var#3294jasonish wants to merge 1 commit into
Conversation
| sc_path = [".", "rust", "target", "release", "suricatasc"] | ||
| if "DEBUG" in suricata_config.features: | ||
| sc_path[3] = "debug" | ||
| cargo_build_target = os.environ.get("CARGO_BUILD_TARGET") |
There was a problem hiding this comment.
Setting CARGO_BUILD_TARGET is another way, but in this case, I don't want to alter the cargo build environment as it can affect the build of the included eve validation program.
There was a problem hiding this comment.
Could you use a SURICATASC_BUILD_TARGET ? if this is just about the target.
I find rust's way hard to find where my binary was built :-/
There was a problem hiding this comment.
This is how we pick up the target between release and debug builds. Its not related to this PR.
inashivb
left a comment
inashivb
left a comment
There was a problem hiding this comment.
Seems to be picked up and working as intended. 🚀
|
Why do you need this ? |
When Rust is built with ASAN, it requires using a --target string which differs from the default. So it is to run with the suricatasc/suricata we just built. |
catenacyber
left a comment
catenacyber
left a comment
There was a problem hiding this comment.
I do not like this, as it is not elegant but it does the work
And the problem I do not like is how rust picks different subdirectories to build binaries
So, approving here since I do not have a better idea
I think it's the auto-picking you don't like, which is pre-existing. This new one is to handle a specific case where the caller specifically knows where the binaries exist that cannot automatically be determined. I think that will be clearer when I can do the Suricata side of the PR. Your point is valid, but I don't see how it relates to this PR. |
4 participants
Needed for a new Rust+ASAN CI build configuration.