As I said in the other project, I feel like a cmake init script is something we really needed and this is quite a good start!
I do see the problem though that cmake is quite opinion based in many ways. Obviously there are some best practices like use targets everywhere. But there are a lot of things, which are discussable or completly based on preference.
So two common acceptable options would be:
Make it configurable
Don't do it if it's controversial
The first option is great for many things, but making everything configurable can be too much at some point. You don't wanna go through a 2h init setup questions neither is it something you wanna maintain I suppose.
So just asking for important stuff like you do now seems good to me.
Just not doing controversial things isn't the worst thing either. At some point it's good to not implement too much, which 80% don't agree with.
But I see some points that are controversial, a pain in the ass to make too configurable, but relevant to a lot of people. One of these is probably dependency management. There are a few options, which one could make configurable. But for all the methods there are also a few ways you could do it.
So I want to propose a general mechanism to deal with this thing. For things that are important and need a decision, just decide. But open up an issue where people can discuss about it. And then document why in particular you made decision xyz and how people could tweak it perhaps, if it doesn't fit for them. This way we have sort of "best practices" and also document them.
In such starter templates I often wonder if there is any rationale behind some certain things. At least for more complex stuff.
An example: Say we add support for a testing framework (GTest) and allow one to use find_package or FetchContent for it (or CPM .. or git submodule or ...).
Say then we want to add the FetchContent part ... how would you do it? Where put the call? When call FetchContent ... when MakeAvailble?
There are a few options here.
One good approach is creating a "dependencies" folder, then list all FetchContent() Calls and then make a folder for each dependency and put in there each MakeAvailable Call. This is one of many approaches, a good one I would say. For a lot of users it might be super confusing why anyone would do it like this.
There are a few reasons here:
Putting it in a subdirectory leads to a clean separation (every seen this huge single root Cmake Files?)
Listing all FetchContent Calls first is more efficient in case dependencies share dependencies. Also allows to overwrite a few things
Putting all MakeAvailable Calls in a new file / folder puts them in a new scope. Therefore variables can be set just for that particular project. For example say you need LIB XYZ as shared, put a set(BUILD_SHARED_LIBS ON) before ... works and doesn't affect anything else
...
It doesn't mean this is the perfect or only approach. But I think it's better to include something than nothing, especially if a lot of people need it. But without any explanation it would be weird for a lot of people. And perhaps this is also something not one person alone should decide, at least not if the overall goal is to make this the "agreed best practice init script".
So a discussion issue + documentation on the decision (with perhaps background information) for all these things would help a lot I would say.
As I said in the other project, I feel like a cmake init script is something we really needed and this is quite a good start!
I do see the problem though that cmake is quite opinion based in many ways. Obviously there are some best practices like use targets everywhere. But there are a lot of things, which are discussable or completly based on preference. So two common acceptable options would be:
The first option is great for many things, but making everything configurable can be too much at some point. You don't wanna go through a 2h init setup questions neither is it something you wanna maintain I suppose. So just asking for important stuff like you do now seems good to me.
Just not doing controversial things isn't the worst thing either. At some point it's good to not implement too much, which 80% don't agree with.
But I see some points that are controversial, a pain in the ass to make too configurable, but relevant to a lot of people. One of these is probably dependency management. There are a few options, which one could make configurable. But for all the methods there are also a few ways you could do it.
So I want to propose a general mechanism to deal with this thing. For things that are important and need a decision, just decide. But open up an issue where people can discuss about it. And then document why in particular you made decision xyz and how people could tweak it perhaps, if it doesn't fit for them. This way we have sort of "best practices" and also document them. In such starter templates I often wonder if there is any rationale behind some certain things. At least for more complex stuff.
An example: Say we add support for a testing framework (GTest) and allow one to use find_package or FetchContent for it (or CPM .. or git submodule or ...). Say then we want to add the FetchContent part ... how would you do it? Where put the call? When call FetchContent ... when MakeAvailble? There are a few options here.
One good approach is creating a "dependencies" folder, then list all FetchContent() Calls and then make a folder for each dependency and put in there each MakeAvailable Call. This is one of many approaches, a good one I would say. For a lot of users it might be super confusing why anyone would do it like this. There are a few reasons here:
It doesn't mean this is the perfect or only approach. But I think it's better to include something than nothing, especially if a lot of people need it. But without any explanation it would be weird for a lot of people. And perhaps this is also something not one person alone should decide, at least not if the overall goal is to make this the "agreed best practice init script".
So a discussion issue + documentation on the decision (with perhaps background information) for all these things would help a lot I would say.