Open egorpugin opened 8 years ago
Looks very nice!
When it downloads packages, does it do this to the project's directory, or to a central directory?
Your getting started doc says "It will use all files it found in the dependency dir.". Does it do this scanning for source files only when the project does not have a CMakeList.txt, or always?
Oh, it's really internal detail. :)
Anyway...
CPPAN generates CMake files itself. It does not use any prepared files (CMakeLists.txt).
So, it always uses file(GLOB_RECURSE src "*")
.
CPPAN spec file should define sources to use, so globbing becomes possible.
There's another option to exclude unneeded sources.
At the last chance there are very useful CMake macros that can be used to remove files from ${src}. (spec file supports raw CMake insertions to provide the highest control over building when it's really needed.)
Upd.: cppan.yml (specification file) should state the sources ONLY (and a license file). I'm not interested in repacking all projects' stuff like docs etc. (And I'm thinking for future how it is possibleto intergrate tests/bench support, but at the moment only shources should be provided.)
Hmm, that doesn't sound like a good idea. A lot of projects come with a CMakeList.txt, which will define how to compile the project, from which sources, with what flags and defines, and where includes live etc. much more accurately.
Yes, but in the beginning I targeted C++ Modules which won't come in c++17. With modules it will be easy to have only sources. Compilers will do other work.
But now it is possible to specify include dirs, definitions, compiler, linker settings in cppan.yml
. So, it's possible.
But you don't want to have to duplicate all these settings that already exist in CMakeLists.txt in yet another build file.
Seems we have to do it now.
What if we elaborate this idea?
CPPAN supports building itself with cppan --build myfile/mydir
. Something like cmake.
So generally, for many projects cmake configuration won't be required - it will be right in spec file.
Spec file tells server how to handle files and tells how to build them via generated CMakeLists.txt.
The issue here is how to handle 1) tests 2) examples 3) benchmarks ( 4) docs too? ). Right now I don't have these answers, but I'm thinking about it.
Hey guys!
@egorpugin What is the current status regarding this issue?
@gwvo is right when he says that cppan
should probably base itself on CMakeLists.txt
if the file already exists in the repo. Do you have plans for this?
The issue here is how to handle 1) tests 2) examples 3) benchmarks ( 4) docs too? ).
Current design is not very suitable for this. I came to this idea on importing large scale projects. Those items will be handled in cppan2 and handled very easily.
Do you have plans for this?
No plans for reading CMakeLists.txt
at the moment (and probably at all).
Hey @gwvo
Here is my removed (by ms guys) comment from vcpkg issue page in case if you didn't read it. :)
C++ Archive Network manages dependencies, versions, different OSs (it's crossplatform from very beginning), handles crossplatform builds very easy (build will inherit your current project settings and autocrossplaform all deps). All builds are cached too - you build your dependency only once. Static/shared mt/md different toolchains (vc11, vc12,vc14, clangX.X, gcc-X) are handled and supported out of the box. It also stores sources on its site, so they shouldn't be lost. And more to come.