On 13. August 2014 21:40:34 MESZ, Nagger wrote:
>But what I really miss is an "--update" option for CMake which is doing
>
>all the work (updating if possible, configuring if necessary)
>internally. It would use the implementation of 'cmake --build' to
>trigger a re-configure and if that is no
Am 13.08.2014 21:59, schrieb Paul Smith:
On Wed, 2014-08-13 at 21:40 +0200, Nagger wrote:
Does anyone already came up with a good solution? Isn't this a common
problem?
I'm not sure about the other generators, but the makefile generator has
this built-in; that is, if the makefiles detect that
On Wed, 2014-08-13 at 21:40 +0200, Nagger wrote:
> Does anyone already came up with a good solution? Isn't this a common
> problem?
I'm not sure about the other generators, but the makefile generator has
this built-in; that is, if the makefiles detect that a cmake file has
changed it will re-run
Hello,
For our Continuous Integration tests we need fast incremental builds
(only build what has changed).
This also includes that CMake only has to run if necessary (some
CMakeLists.txt changed).
It seems there is no beautiful/portable/generator-independent way to do
this?!
Fortunately we m
Are these actually C++ files? If so then they should really have a C++
extension (like .cp or .cxx). It may be a good idea in general since other
build tools may run in to the same sort of issue of assuming they are C
files. A few other tips: first, by placing all your source files in a list
var
2014-08-13 16:16 GMT+0200, Mark Abraham :
> On Wed, Aug 13, 2014 at 7:12 AM, marco restelli
> wrote:
>
>> 2014-08-13 15:53 GMT+0200, Mark Abraham :
>> > On Wed, Aug 13, 2014 at 3:18 AM, marco restelli
>> > wrote:
>> >
>> >> Hi Petr,
>> >>thanks, very informative!
>> >>
>> >> 2014-08-13 9:20 G
On Wed, Aug 13, 2014 at 7:12 AM, marco restelli wrote:
> 2014-08-13 15:53 GMT+0200, Mark Abraham :
> > On Wed, Aug 13, 2014 at 3:18 AM, marco restelli
> > wrote:
> >
> >> Hi Petr,
> >>thanks, very informative!
> >>
> >> 2014-08-13 9:20 GMT+0200, Petr Kmoch :
> >> > Hi Marco.
> >> >
> >> > Sa
2014-08-13 15:53 GMT+0200, Mark Abraham :
> On Wed, Aug 13, 2014 at 3:18 AM, marco restelli
> wrote:
>
>> Hi Petr,
>>thanks, very informative!
>>
>> 2014-08-13 9:20 GMT+0200, Petr Kmoch :
>> > Hi Marco.
>> >
>> > Sane compilers allow later command-line options to override earlier
>> > ones,
>>
If project Y needs to link to project X, you could build project Y with
ExternalProject_Add and list project X in the DEPENDS parameter.
http://www.cmake.org/cmake/help/v3.0/module/ExternalProject.html
On Wed, Aug 13, 2014 at 9:39 AM, Hans van den Bogert
wrote:
> I see thanks, so install_dir h
On Wed, Aug 13, 2014 at 3:18 AM, marco restelli wrote:
> Hi Petr,
>thanks, very informative!
>
> 2014-08-13 9:20 GMT+0200, Petr Kmoch :
> > Hi Marco.
> >
> > Sane compilers allow later command-line options to override earlier ones,
> > so what you're doing should be fine. Unfortunately, I kno
I see thanks, so install_dir has a different meaning than the eventual install
dir of the external project, I thought there would be some ‘magic’ where the
ExternalProject functions would override the the prefix of, in this case,
project x.
I still have one issue, perhaps I should start a new
See, for example:
https://github.com/OpenChemistry/openchemistry/blob/master/CMakeLists.txt#L24
A common CMAKE_INSTALL_PREFIX is used for all OpenChemistry
ExternalProject builds that are driven by CMake.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at
If x is a CMake-driven project, you'll also need to explicitly set
CMAKE_INSTALL_PREFIX when configuring. If not, there's likely a
"--prefix" arg for configuring... One of those also has to be set to
install to a non-default location.
The PREFIX arg for ExternalProject is only used to organize
Hi,
I’m using ExternalProject, but the documentation does not really reflect what I
am witnessing
I have a Project X which is included through ExternalProject in Project A
Project X has no PREFIX set in its CMakeLists
I include project X like this:
include(ExternalProject)
ExternalProj
Hi Petr,
thanks, very informative!
2014-08-13 9:20 GMT+0200, Petr Kmoch :
> Hi Marco.
>
> Sane compilers allow later command-line options to override earlier ones,
> so what you're doing should be fine. Unfortunately, I know some Fortran
> compilers are not sane in this regard.
Here, I would r
Hi Marco.
Sane compilers allow later command-line options to override earlier ones,
so what you're doing should be fine. Unfortunately, I know some Fortran
compilers are not sane in this regard.
If you really need to solve this by explicitly modifying the global list
for a particular file, the on
16 matches
Mail list logo