pitchfork
pitchfork copied to clipboard
vector-of-bool
I am uncomfortable with the inconsistency of sometimes having a /src/ folder and sometimes not.
If a project with submodules is a directed graph, thus requiring all submodules to be siblings, then simply put all submodules in folders under the /src/ subfolder. For consistency, always place the main submodule in /src/main/, and place the other submodules in their own folders as sibling folders to /main/. If submodules are actually useful as separate libraries, then place them into subfolders of /lib/ and treat /lib/ with the rules currently ascribed to /external/. This, then, makes /external/ redundant, so it can be eliminated.
When most people think of "Libs" they think of "external libraries." However, within the context of Pitchfork," "Libs" takes on a different meaning, as "private submodules used only within the current project." This is also inconsistent.
The above suggestion does not take into consideration the debate as to whether external libraries should even be copied to the project folder. If it is decided that external libraries should not be copied to the project folder, the /lib/ folder could be used to hold simlinks to the original folders for those libraries, OR the /lib/ folder could also be eliminated and proper makefiles could be constructed to point to where the external libraries are stored.
Note: I am also using the singular version for all these folder names.
I agree that the current usage of "libs" sounds a little limiting. I wish it was "modules" or "submodules" or "components" instead.
Each submodule is its own tree of directories though so if you just chuck them all into src wouldn't you get something that looks like this:
./src/submodule-a/docs
./src/submodule-a/include
./src/submodule-a/src
./src/submodule-b/docs
./src/submodule-b/include
./src/submodule-b/src
It looks a bit strange to me with the child 'src' inside the parent 'src' and you also end up putting public headers and documentation into the top-level src directory which I don't like at all.
You make a very good point about how using separate /src/ and /include/ folders necessitates parallel folder structures under these folders. And I'm rarely a fan of maintaining parallel folder structures where different parts of a specific thing are stored in different branches of a tree, but with identical names. In other words, when one wants to separate different specific things (such as a "submodule" of code) while also separating similar parts of said things based on category (such as public code or private code) I am always in favor of keeping all the parts of said specific thing closer together in the tree, rather than keeping parts that are merely in a similar category closer together.
In yet other words: I would prefer...
/src/submodule-a/private/ /src/submodule-a/public/ /src/submodule-b/private/ /src/submodule-b/public/
... over...
/src/submodule-a/ /src/submodule-b/ /include/submodule-a/ /include/submodule-b/
...or even...
/src/submodule-a.cpp /src/submodule-b.cpp /include/submodule-a.h /include/submodule-b.h
Now, I know that one of the latter two were chosen (in "legacy times") because it is easier to just copy everything in an /include/ folder and give it to some "consumer" or "user" of your code. Especially when using the command line. However, we are no longer in "legacy times." We use modern IDEs with macros and scripts and dev-ops built in. I think they can handle copying a few extra files over to the /build/ folder for us.
Unfortunately, for a community that is literally in the most futuristic industry ever, there are a heck of a lot of people who are steeped in (AKA "still stuck in") tradition and "that's the way we've always dunnit - ism."
So, if some of us started using my preferred approach, would that do anything other than piss off sticklers for "legacy" folder structures? Unfortunately, I'm guessing not.
What to do? I have about concluded that I am just gonna use my own friggin' system, and to hell with everyone else. A) The chances of someone else using my code is slim. And, B) If someone does use my code but cannot figure out how to adapt to my folder structure (or adapt my folder structure to their workflow), then perhaps my folder structure is the least of their problems.
In the end, I think the best solution is to make sure IDEs are designed to handle different folder structures for different submodules, all within the same project (or within what Visual Studio calls a "solution").
