On 11.04.24 11:44, Boris Kolpackov via Boost wrote:
- bdep creates a <project_name>/<project_name> hierarchy. I assume the outer <project_name> directory is the package and the inner <project_name> is the project within the package. But wait, there's one more level! I can't put my build directories in the inner /or/ the outer <project_name>, so in practice I've got three levels: <project_name>/<project_name>/<project_name>.
That's the default structure and there is rationale[1] for it, though as most things in this area, it's a trade-off and not everyone agrees with the choices we've made.
I have been using the canonical layout for the purpose of following along with the Getting Started Guide. I realize that some aspects of this cane be changed, but others seemingly can't. This is the layout I want: <project_name> + builds <- not in version control + configuration1 + configuration2 + source + <super_project_name> + <project_name> + <project>.hpp + <project>.cpp + <build_configurations_files> <- in version control I find the use of <super_project_name> useful to separate internal libraries and external libraries, and to prevent namespace pollution. I use this include style: #include "super_project_name/project_name/project.hpp" Double quotes instead of angle brackets because the file I'm including is not from the standard library, but always with both super_project and project names. The important bits here that Build2 doesn't seem to like: - Builds go under the main project directory. One project, one top-level directory (with as many subdirectories as needed). - Build configurations are versioned.
- I need to specify the name for each build configuration twice, once for the @name and once for the directory.
Hm, not sure where you got this impression. The only time you need to specify both is when creating the configuration. Even in this case the directory is actually optional and if you don't specify it, you will get ../<project>-<name> by default.
Yeah, I really don't like these <project>-<configuration> directories at the same level as the main project. Hence the need to manually specify a different directory.
- It wants me to use git. I strongly prefer fossil as my version control system.
You can use build2 without git. You will loose quite a bit of "nice to have" functionality, mostly in bdep, but it's doable.
I know I can, but I don't like losing "nice to have" functionality. Especially when I'm just getting started with Build2 and I don't know what that functionality is or how nice it is.
- Build configurations appear to be stored in a sqlite database, not in a readable and editable text file.
It's a bit more nuanced that that: some information (usually the one you don't want to edit manually) is stored in the SQLite database, while things like compiler, options, etc that you have configured are stored in plain text files that you are welcome to edit. > Continuing with the above example:
$ cat ../hello-clang/build/config.build
That's a relief, but the configuration options are stored with the build artifacts? That's awkward if I want the configuration options in version control while keeping the build artifacts outside. -- Rainer Deyke (rainerd@eldwood.com)