Correction:
*I haven't tried this yet, but I am hoping it will work well* - Pull Put my
sub-projects (my own custom libraries) into their own independent git repos
and pull them into my main project using "FetchContent". Then when I run
"FetchContent" it will checkout the sub-projects and I will
Hi Craig,
Thank you for the detailed description!
To answer some of your questions:
- This project will not be incorporated into a Linux distribution,
however I would like to keep it cross platform and it should work on
Windows, Mac, and Linux.
- All of the pieces of the project
On Tue, Feb 19, 2019 at 12:46 PM Timothy Wrona
wrote:
> I have been working on a new C++ project and I am trying to decide whether
> I should use CMake as my package management system or if I should use a
> dedicated package management tool such as Conan.
>
> For more information on Conan see:
I have been working on a new C++ project and I am trying to decide whether
I should use CMake as my package management system or if I should use a
dedicated package management tool such as Conan.
For more information on Conan see: https://conan.io/
I am trying to understand the main difference
On 5/17/2018 11:46 AM, Brad King wrote:
On 05/17/2018 05:56 AM, Kinga Kasa wrote:
cmake running for hours and hours (stuck at saying Configuring done,
eventually it will finish, but it runs for hours).
That's not expected. Even on projects with tens of thousands of
source files and thousands
On 05/17/2018 05:56 AM, Kinga Kasa wrote:
> cmake running for hours and hours (stuck at saying Configuring done,
> eventually it will finish, but it runs for hours).
That's not expected. Even on projects with tens of thousands of
source files and thousands of libraries and executables it
Dear CMake Developers Team,
I have a question regarding CMake. We are currently working on a rather big
project and we would like to build it with CMake.
The structure of the project looks like the following: we have a root directory
where we have 50+ subdirectories with projects in them with
On 05/17/2016 01:42 PM, Nicolas Desprès wrote:
> That's great! The code is way cleaner this way. I have tested it with
> my generator and it works fine.
Great, thanks for trying it out. We'll see how nightly testing goes tonight
but otherwise I think this topic is all set. Thanks for
On Tue, May 17, 2016 at 4:23 PM, Brad King wrote:
> On 05/13/2016 07:19 PM, Nicolas Desprès wrote:
> > Ok. See the new implementation
>
> Thanks. I've rebased your topic on 'master' after the style transition
> commit and updated the style accordingly. Then I split the
On 05/13/2016 07:19 PM, Nicolas Desprès wrote:
> Ok. See the new implementation
Thanks. I've rebased your topic on 'master' after the style transition
commit and updated the style accordingly. Then I split the topic up into
more commits and simplified the prefix insertion logic a bit.
I've
On 05/13/2016 03:25 PM, Brad King wrote:
> so for now please make your logic recognize this case and work around it.
Please split this into two commits to move hunks like this:
> + this->TargetAll = this->NinjaOutputPath("all");
> + this->CMakeCacheFile =
On 05/13/2016 12:13 PM, Nicolas Desprès wrote:
> with a value that looks like this:
> "-Wl,-bundle_loader,/Users/polrop/Documents/cmake/_build
> ninja/Tests/ExportImport/Export/testExe2"
>
> lie on the caller site because the "if (li->IsPath)" in OutputLinkLibraries()
> should not be true for
On Thu, May 12, 2016 at 10:07 PM, Brad King wrote:
> On 05/12/2016 02:16 PM, Nicolas Desprès wrote:
> > All done. Thank you for taking a look.
> > https://github.com/nicolasdespres/CMake/commits/ninja-output-path-prefix
>
> The RunCMake.NinjaOutputPathPrefix test fails for
On 05/12/2016 02:16 PM, Nicolas Desprès wrote:
> All done. Thank you for taking a look.
> https://github.com/nicolasdespres/CMake/commits/ninja-output-path-prefix
The RunCMake.NinjaOutputPathPrefix test fails for me when I have
the CMake source and build trees in a directory with a space in
the
On Thu, May 12, 2016 at 3:16 PM, Brad King wrote:
> On 05/12/2016 06:16 AM, Nicolas Desprès wrote:
> > Brad has just sent a notification email about an upcoming feature freeze.
> > Do you think we could have this feature merged before?
>
> I'll take a look. Please rebase
On 05/12/2016 06:16 AM, Nicolas Desprès wrote:
> Brad has just sent a notification email about an upcoming feature freeze.
> Do you think we could have this feature merged before?
I'll take a look. Please rebase on 'master' to resolve conflicts
and also reconcile with the
Hi Ben,
Brad has just sent a notification email about an upcoming feature freeze.
Do you think we could have this feature merged before?
Regards,
Nicolas
On Sun, Mar 20, 2016 at 1:47 PM, Nicolas Desprès
wrote:
>
>
> On Wed, Mar 9, 2016 at 9:41 PM, Ben Boeckel
On Wed, Mar 9, 2016 at 9:41 PM, Ben Boeckel wrote:
> On Tue, Mar 08, 2016 at 12:36:31 +0100, Nicolas Desprès wrote:
> > Did you have a chance to review my patches?
>
> So I looked at it today, and it looks good overall. A few niggles:
>
Thanks
>
> +inline bool
On Tue, Mar 08, 2016 at 12:36:31 +0100, Nicolas Desprès wrote:
> Did you have a chance to review my patches?
So I looked at it today, and it looks good overall. A few niggles:
+inline bool cmEndsWith(const std::string& str, const std::string& what)
+{
+ assert(str.size() >= what.size());
On Tue, Mar 08, 2016 at 12:36:31 +0100, Nicolas Desprès wrote:
> Did you have a chance to review my patches?
Sorry, not yet. I hope to have a peek at it today or tomorrow.
--Ben
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
Ben,
Did you have a chance to review my patches?
Cheers,
Nicolas
On Sunday, February 14, 2016, Nicolas Desprès
wrote:
> Ben,
>
> I have pushed a complete version of the patch here:
> https://github.com/nicolasdespres/CMake/commits/ninja-output-path-prefix
>
> Since
Ben,
I have pushed a complete version of the patch here:
https://github.com/nicolasdespres/CMake/commits/ninja-output-path-prefix
Since the last push, I have addressed the comments you made in your
previous review (i.e. move some code to cmAlgorithm.h) and added a
RunCMake.NinjaOutputPathPrefix
On Fri, Jan 22, 2016 at 17:34:03 +0100, Nicolas Desprès wrote:
> I have pushed a first draft of the patch here:
>
> https://github.com/nicolasdespres/CMake/commit/67a4faad47378c07c97a29dd229d6f9fa500763b
>
> I have tested with a small project and it looks good.
Looks like a good start to me as
Ben,
I have pushed a first draft of the patch here:
https://github.com/nicolasdespres/CMake/commit/67a4faad47378c07c97a29dd229d6f9fa500763b
I have tested with a small project and it looks good.
I would like to add some regression tests but I don't know from where to
start.
The principle would
Hello,
I would like to be able to use a build.ninja file generated by CMake as a
subninja file of a super build.ninja file generated by a custom generator.
This way I could include a CMake projects in a bigger one.
Currently, I call ninja recursively to build the CMake sub-project. But
this
On Wed, Jan 6, 2016 at 6:25 PM, Ben Boeckel wrote:
> On Wed, Jan 06, 2016 at 11:14:32 +0100, Nicolas Desprès wrote:
> > To enable this type of generation, the "top/" directory must be passed to
> > CMake somehow. An environment variable or a CMake variable called
> >
On Wed, Jan 06, 2016 at 19:26:11 +0100, Nicolas Desprès wrote:
> Is that variable already available or a name suggestion? I cannot find any
> reference to it neither in the source nor in the documentation.
It's a suggestion.
> This is acceptable for me since I have a custom generator that would
On Wed, Jan 6, 2016 at 7:35 PM, Ben Boeckel wrote:
> On Wed, Jan 06, 2016 at 19:26:11 +0100, Nicolas Desprès wrote:
> > Is that variable already available or a name suggestion? I cannot find
> any
> > reference to it neither in the source nor in the documentation.
>
>
On Wed, Jan 06, 2016 at 11:14:32 +0100, Nicolas Desprès wrote:
> To enable this type of generation, the "top/" directory must be passed to
> CMake somehow. An environment variable or a CMake variable called
> CMAKE_NINJA_TOP_BUILD_DIR would do the trick.
I think CMAKE_NINJA_OUTPUT_PATH_PREFIX
Charles,
I'd like to comment on a minor issue:
CMakeLists.txt files don't specify user-specific data like source and build
dirs (for a reason) yet your POC listfile contains this line:
cmake.init("Ninja", "/media/dev/src/cmaketest",
"/media/dev/build/cmaketest")
which sets the source and
I took the time to make it work again, so I pushed it here:
https://github.com/packadal/CMake/tree/cmake-python
The whole branch is ugly as can be, and because I started with an old CMake
and recently rebased, the python abstraction might be bloated already, but
it works in the nominal case, and
Yes, this is POC-only.
I felt too lazy to make an argparse object and properly perform these tasks.
Obviously, the generator and source dir should be arguments.
The build dir should be the execution dir of the script, to mimic CMake
behavior.
This should not be difficult, but as I said I wanted
Charles Huet wrote:
> * cmCacheManager::AddCacheEntry was made public, as cmake::Configure
> cannot be used from python (it check for the existence of a CMakeLists.txt
> file, which does not exist in this scenario) and the cache variables it
> sets seem to be necessary.
Because of the above, I
Hi,
Because of the above, I worry that you are basing your work on an old
> version of CMake. As of April 2015 cmState is used as the interface to the
> cache.
Yeah, that is sadly right. I wanted to rebase on master before publishing,
thinking it should not be too hard, and I have lots to
Hi,
I'd like to have a discussion about using CMake as a library from python,
and by that I mean not writing CMakeLists.txt files, but python code that
then uses the CMake generators and Find*.cmake in order to leverage both
the power of CMake and Python.
First, a bit of background on the idea
On 11/02/2015 04:19 PM, Chris Bieneman wrote:
>> What we need is for try_compile to learn to check for some global
>> option to be set by a toolchain or platform information module that
>> tells it there is no linker. Then try_compile could handle this
>> case by using add_library(... STATIC …).
On 10/30/2015 03:05 PM, Chris Bieneman wrote:
> equivalent of try_compile that will test building a static archive
> instead of an executable?
For the "source file" signature of try_compile there is currently
no such option. The try_compile command also has a mode that builds
an entire source
> On Nov 2, 2015, at 11:52 AM, Brad King wrote:
>
> On 10/30/2015 03:05 PM, Chris Bieneman wrote:
>> equivalent of try_compile that will test building a static archive
>> instead of an executable?
>
> For the "source file" signature of try_compile there is currently
> no
CMake-developers,
An issue with our compiler-rt CMake builds came to my attention yesterday, and
I’m wondering how to best deal with it.
Compiler-rt is a bit of a special flower. One part of it is a bunch of runtime
libraries, which are basically just dylibs and static archives, nothing to
Hi,
How can use Cmake builder for Eclipse IDE is possible?
I want to build the MITK project in eclips IDE
Thanks in advance
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support
On Monday 22 November 2010, Alan W. Irwin wrote:
On 2010-11-22 21:55+0100 Alexander Neundorf wrote:
Hi,
there can be the case that a package which has been built with cmake,
should be used in a project which doesn't use cmake.
There is a feature request that cmake should help with
Hi,
there can be the case that a package which has been built with cmake, should
be used in a project which doesn't use cmake.
There is a feature request that cmake should help with generating pkg-config
pc-files: http://public.kitware.com/Bug/view.php?id=11446
I don't like that idea, because
On 11/22/2010 03:55 PM, Alexander Neundorf wrote:
I have a slightly different idea: instead of having cmake generate pc-files,
modify/extend cmake so that it can be used similar to pkg-config by projects
which don't use cmake as their buildsystem.
Interesting.
It already somewhat works:
$
On Monday 22 November 2010, Brad King wrote:
On 11/22/2010 03:55 PM, Alexander Neundorf wrote:
I have a slightly different idea: instead of having cmake generate
pc-files, modify/extend cmake so that it can be used similar to
pkg-config by projects which don't use cmake as their
On 2010-11-22 21:55+0100 Alexander Neundorf wrote:
Hi,
there can be the case that a package which has been built with cmake, should
be used in a project which doesn't use cmake.
There is a feature request that cmake should help with generating pkg-config
pc-files:
45 matches
Mail list logo