Open NOhs opened 5 years ago
An example where the current solution is kind of "meh", is for Python projects which you might want to install in-place for development purposes ("pip install -e .") which would result in obj and dep files landing in your Python package folder instead of only the compiled Python C++ module.
In the Python package case, can one not specify the files that should be included, e.g. the "bin" folder?
To me, this sounds similar to the idea of being able to "package", i.e. to have a command, which places a new folder next to "build", e.g. called "package", in which per target the entire set of binaries with dependencies is placed. Is something like this what you have in mind?
In the Python package case, can one not specify the files that should be included, e.g. the "bin" folder?
I think this is currently not possible with clang-build.
What I meant is that for pip install
you would usually have a "setup.py" or something that specifies the files that should be included, which is why I think this issue might be orthogonal to clang-build
.
Maybe I'm just misunderstanding the use-case you are describing. How would you structure the folders to suit your case?
It's not about packaging, more about that the package you cloned/updated/whatever contains files that do not belong there and clutter your editor, you can still use it, as Python ignores these other files, but it just isn't clean.
only copy the library to a specific folder instead of all the obj/dep file junk as well
PR #98 introduced CLI flags (unfortunately not well-tested anymore):
--bundle
to gather dependencies into a dependent targets bin/lib folders--redistributable
to generate a folder containing only those parts of the build-folder that are needed for redistribution: public headers and binariesWould those (theoretically) achieve what you have in mind?
I can see the need to specify the output directory. I am just not sure, the way it is implemented now is a good approach. Currently, executable, dependency file and object files will ALL be placed in the same location (modulo subfolder names). This is hardcoded into the
Compilable
class. I am wondering if just keeping a default output structure would be more reasonable and instead heaving some post build actions one can define. This way, clang-build would be a bit "cleaner", and we would add the flexibility (if needed) to e.g. only copy the library to a specific folder instead of all the obj/dep file junk as well.