The goal behind Evoke is to rely solely on the code itself, and the directory structure around the code, to determine what makes up which components, and which components are which type.
The Beman project setup is almost perfect for it - including cloning a bunch of Beman projects into separate folders including cross-dependencies - except for the examples folder containing multiple examples, presumably with separate main() functions.
If each of the examples are just a function to be triggered through a main entry point for the examples, then it will work as is. However, if they are supposed to be separate executables, then it would (according to Evoke’s logic) need each of them to be its own folder.
Would this be an acceptable change?
There’s a teensy thing too - the test folder it expects is “test”, not “tests” - but that’s one that I think Evoke should just fix instead.
So to be clear are you suggesting evoke for the role of taking say 3 ranges repos and combining them into a single ranges repo?
Note that if you stare carefully at the Beman standard we’re doing are best to say cmake and python are about the extent of the tool chain (outside of compilers, coverage, documentation, and package managers optionally). So w.r.t adding another thing we’ll want some really compelling use cases.
I’m suggesting that by making a minor tweak to the guidance for one folder, that the whole thing already does everything evoke needs/requires, and wouldn’t need a single byte of build configuration anywhere.
I’m not trying to add any work, only trying to tune one rule, which would make that work.
If that’s not possible, then that’s okay too - I’ll just have to work around it locally.
Well for that I think evoke should be adapted and not Beman. Having many small stand alone example files is a pretty common pattern in open source and I wouldn’t want to prevent authors from using that pattern. Forcing a subdirectory per file doesn’t seem right – to pick one, in boost date-time there’s subdirectories in examples all with several files…
If I understand correctly, when looking at a folder with .cpp files, without more information, you cannot determine the type (e.g., library, executable) or quantity of build artifacts they produce. Evoke wants you to be able to determine this based on directory structure.
I like the theory behind that, but where tests predominantly consist of a single file, it’s tedious to maintain an extra containing directory. Rust’s cargo build system seems to share Evoke’s goals and gets around this tedium (in the case of examples) by treating examples/foo.rs as a single-file executable and examples/bar/*.rs as a multi-file executable (bar). What are your thoughts on that @dascandy / @Jeff-Garland ?
I’d note that the vast majority if not all Beman libraries currently have multiple .cpp files for tests - each with their own main. In my experience with this with most libraries this is done to split tests into logical groups for maintenance and parallel compilation. Building a library in the test directory to support tests is super rare…
I think the Rust assumption is more in line with what I’d expect. Still a bigger (see also execution) library could easily have example subdirectories with single file examples.
In the case of Beman we’re 100% standard on cmake which allows for the generation of compile_commands.json – shouldn’t a tool like evoke consider using the actual generated commands instead of just a directory?