Adds a subcommand which updates a project's src/CMakeLists.txt from the source tree. Only supports CMake.

• Automatic detection of project base-dir (for CMake).
  • Ascending filesystem iterator. Moves up a directory with each increment.
  • Use Boost::filesystem as a polyfill rather than std::experimental::filesystem
• Edit the src/CMakeLists.txt file
• Add an update subcommand. When the build system is specified as cmake, performs the operation.

This inserts source files from the tree by scan the CMakeLists.txt file for function calls containing # sources comment. From that comment to the end of the function, everything is replaced with the globbed sources.

I don't intend on this being a permanent solution. My vision is to parse the CMakeLists.txt file and use some heuristics to determine where to place the source list.

This is very limited. It only globs for source files and header files; there's currently no option to glob for only one kind. It does skip sources directly under src/; it only grabs sources under a subdirectory of src/. It also only searches src/; it doesn't look at include/ or tests/

The git history for this branch is kind of messy. The commits are not that clean; there may be some commits which don't build, and there are some commits which are incomplete progress

Hello,

I would like to evaluate pitchfork tool. Unfortunately, I can't configure it.

I use cmake 3.14.4 and conan 1.11.1

The configure step fails at zlib. When inspecting my folders, I see a file C:\\Users\\MartyLake\\.conan\\data\\zlib\\1.2.11\\conan\\stable\\package\\46fecbf5b55c9a04d9e1ce376246b1f9e619c3b7.dirty of size 0 instead of (I suppose?) a folder that would contain the zlib lib.

Here is the end of cmake log:

zlib/[email protected]/stable: 
Calling package()

ERROR: zlib/[email protected]/stable: Error in package() method, line 185
	self._rename_libraries()
while calling '_rename_libraries', line 133
	os.rename(current_lib, os.path.join(lib_path, "zlib.lib"))
	FileNotFoundError: [WinError 2] Le fichier spécifié est introuvable: 'C:\\Users\\MartyLake\\.conan\\data\\zlib\\1.2.11\\conan\\stable\\package\\46fecbf5b55c9a04d9e1ce376246b1f9e619c3b7\\lib\\zlibstatic.lib' -> 'C:\\Users\\MartyLake\\.conan\\data\\zlib\\1.2.11\\conan\\stable\\package\\46fecbf5b55c9a04d9e1ce376246b1f9e619c3b7\\lib\\zlib.lib'

CMake Error at build/_pmm/1.3.1/conan.cmake:470 (message):
  Conan install failed [1]:

Call Stack (most recent call first):
  build/_pmm/1.3.1/conan.cmake:495 (_pmm_conan_install_1)
  build/_pmm/1.3.1/conan.cmake:643 (_pmm_conan_install)
  build/_pmm/1.3.1/main.cmake:32 (_pmm_conan)
  build/_pmm/1.3.1/main.cmake:47 (_pmm_project_fn)
  CMakeLists.txt:32 (pmm)


CMake Error at build/_pmm/1.3.1/conan.cmake:500 (message):
  Conan dependencies were not imported (Expected file
  C:/Users/MartyLake/Dev/pitchfork/build/conanbuildinfo.cmake).  You may need to
  run Conan manually (from the build directory).  Ensure you are using the
  'cmake' generator.
Call Stack (most recent call first):
  build/_pmm/1.3.1/conan.cmake:643 (_pmm_conan_install)
  build/_pmm/1.3.1/main.cmake:32 (_pmm_conan)
  build/_pmm/1.3.1/main.cmake:47 (_pmm_project_fn)
  CMakeLists.txt:32 (pmm)


CMake Error at CMakeLists.txt:33 (conan_set_find_paths):
  Unknown CMake command "conan_set_find_paths".

The tests fail with this message:

../../tests/generate.cpp:43
...............................................................................

../../tests/generate.cpp:38: FAILED:
  CHECK_FALSE( diff )
with expansion:
  !Unexpected files in output directory:
    + docs
    + third_party

===============================================================================
test cases: 1 | 1 failed
assertions: 2 | 1 passed | 1 failed

I'm pretty sure this is because git doesn't commit empty directories; it tracks files, not directories.

In the file src/pf/fs.hpp you differentiate between experimental and non-experimental versions of the filesystem include. I have noticed that your *else branch is wrong:

#if STD_FS_IS_EXPERIMENTAL
#include <experimental/filesystem>
namespace pf {

namespace fs = std::experimental::filesystem;

}  // namespace pf
#else
#include <filesystem>
namespace pf {

namespace fs = std::experimental::filesystem;

}  // namespace pf
#endif

It should be: namespace fs = std::filesystem; instead of: namespace fs = std::experimental::filesystem;

Fixes #3 and fixes #8 , along with some stuff which were necessary.

Some comments:

• This fix for #8 is not the best code. It literally copies code from _pf_auto into a new function. Ideally, this new function would share code with _pf_auto rather than copy-paste it.
• The ignored file is called ignore_in_diff. I don't have a preference for the name
• The ignored file is ignored in both the expected case and actual case. It might be better to only ignore it in the expected case, just in case the actual generated directories include the ignored file.

Clang caught some unneeded std::moves which inhibit copy elision:

fs.hpp line 39

inline std::fstream open(const fs::path& filepath, std::ios::openmode mode) {
    std::error_code ec;
    auto            ret = open(filepath, mode, ec);
    if (ec) {
        throw std::system_error{ec, "Open file: " + filepath.string()};
    }
    return std::move(ret); // error: moving a local object in a return statement prevents copy elision [-Werror,-Wpessimizing-move]
}

fs.cpp line 13

std::fstream pf::open(const fs::path& filepath, std::ios::openmode mode, std::error_code& ec) {
    std::fstream ret;
    auto         mask = ret.exceptions() | std::ios::failbit;
    ret.exceptions(mask);

    try {
        ret.open(filepath.string(), mode);
    } catch (const std::ios::failure& e) {
        ec = e.code();
    }
    return std::move(ret); // error: moving a local object in a return statement prevents copy elision [-Werror,-Wpessimizing-move]
}

In both these cases, the return std::move(ret); should simply be return ret;

This is an idea for a subcommand: pf info. Pitchfork has some knowledge about the project, such as the project base directory, or potentially (in the future) the components / source files. Adding a way to query this information would be helpful for scripting.

Even though the enable_testing() function is getting called by pf_auto(...), CTest cannot find any tests.

Adding the enable_testing() call before the call to pf_auto() works, though. Adding the enable_testing() call after the call to pf_auto() does not work. This looks like a CMake bug, either in source or in documentation. It looks like the call to enable_testing() must appear before any tests are defined

To reproduce this, make sure you start with a fresh build directory.

Changes:

• Use /permissive- for MSVC
• Add missing #include <cctype> to mustache (https://github.com/kainjow/Mustache/issues/29)
• Add missing #include <iterator> to tests/compare_fs.cpp
• Changed class eof in pf.cpp to class reached_eof. MSVC complains that eof is ambiguous at catch (const eof&)

Installing conan is pip install --user conan (I like the --user flag; without it I think you need sudo)

To use this:

$ cd build
$ conan install ..
$ cmake -DCMAKE_PROJECT_pitchfork_INCLUDE=$(pwd)/conan_paths.cmake ..

For conan packages which don't properly support non-intrusive cmake integration, it's a bit more work (I write a custom cmake include file that wraps find_package)

Hello, I have a "big" project with mostly C++, but also some python files!

The spec says src is for compilable source (and I wouldnt want to put rogue python files in there anyway), but what would be the best place then? My best guess and what I did until now is a python folder in root basically acting like a src folder.

A similar issue I have now is for packaging. Multiple CMake files could go in a cmake folder. What about deb's control, postinst etc (those are basically package specs: dependencies, things to do on install etc), a debian folder maybe ?

It did make sense for python but now I feel like this is getting out of hand 😅

I have a library (a submodule under libs/) that I want to build with profile-guided optimization. To run the instrumented library to collect profile data, I plan to make a setup where I can choose from multiple small-ish training programs which call functions from the library. Where is a good place to put the source code for the training programs?

• They definitely aren't "source code" in the sense of implementing any functionality of the library.
• They aren't tests because they don't have anything to do with checking the correctness of the code.
• They don't seem quite like "extras" since the library is the core part of the project, and the training programs are an essential part of its build process when doing PGO.
• They definitely aren't data, but they are used to produce data (which shouldn't be checking into version control)
• I do have an apps/ directory as discussed as one option in #30, but PGO training programs just don't feel like "apps" to me. They aren't useful or intended for anything except gathering representative profile data.

I'd like to hear what the authors of this spec think: Would it be "wrong" of me to add a new child directory inside the library's submodule directory just for pgo training program source code?

PFL doesn't address the integration of multiple libraries in one project. The document below offers a possible solution. The Dogfood and the Pitchfork.md

Thank you for taking the time to consider it.

w.r.t. the first paragraph of 4.4 extras/:

I get why platform bindings are not in libs/ as they're not always built and that's a requirement for the submodules in libs/. (Some people may never build the Windows bindings, others never build the Linux bindings ...) But typically one or another of them is always required for any given build. They're at the foundation of the project.

So I'm fine with them in extras but the wording of what goes in extras should be changed ...

Or maybe it's the requirement that stuff in libs/ is always built that should be relaxed ...

But actually, in my own project, I'm putting them as submodules in libs/.

(In fact, I have added another layer inside of libs/ where I group submodules by "category" - I may have multiple implementations of a given service interface, for example, so I put them together under, say, "storage" (one submodule for sqlite, one for filesystem, one for webdav, ...) - and in this way I'll have libs/platform/ and there will be under it windows and linux (macos can go into extras/ with any other contributed stuff...).)

(Pitchfork is well thought-out IMO, thanks for the effort!)

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.