On Wednesday 12 November 2008, Fernando Cacciola wrote:
> Hi Bill,
...
> Ha I see... that is 2.6 specific right?
>
> There are still too many 2.4 versions shiped with Linux et al, and we
> don't want to ask our users to *manually* upgrade cmake when they
> already have one installed, so I'm keeping
Am Wednesday 12 November 2008 17:03:04 schrieb Fernando Cacciola:
> Hi Hendrik,
>
> >>> But it is not backwards-compatible and will fail to link on the new
> >>> version while it worked fine on the old version.
> >>
> >> Why??
> >
> > Because if the ${FOO_USE_FILE} doesn't do what it always does (g
Hi Hendrik,
But it is not backwards-compatible and will fail to link on the new
version while it worked fine on the old version.
Why??
Because if the ${FOO_USE_FILE} doesn't do what it always does (globally
adding this stuff), you _have_ to insert the new macro call to make it
compile again.
Fernando Cacciola schrieb:
> Hendrik Sattler wrote:
>> Bill Hoffman schrieb:
OTOH, it could make sense to do the following:
find_packge( CGAL REQUIRED )
include( ${CGAL_USE_FILE} )
add_executable( program ... )
use_CGAL( program )
>>
Hendrik Sattler wrote:
Bill Hoffman schrieb:
OTOH, it could make sense to do the following:
find_packge( CGAL REQUIRED )
include( ${CGAL_USE_FILE} )
add_executable( program ... )
use_CGAL( program )
so it works now with 2.4, and eventually "upgrade" it to use target
properties in
Bill Hoffman schrieb:
>> OTOH, it could make sense to do the following:
>>
>> find_packge( CGAL REQUIRED )
>>
>> include( ${CGAL_USE_FILE} )
>>
>>
>> add_executable( program ... )
>>
>> use_CGAL( program )
>>
>> so it works now with 2.4, and eventually "upgrade" it to use target
>> prope
Hi Bill,
Fernando Cacciola wrote:
Ha I see... that is 2.6 specific right?
There are still too many 2.4 versions shiped with Linux et al, and we
don't want to ask our users to *manually* upgrade cmake when they
already have one installed, so I'm keeping all compatible with at
least 2.4.5
Fernando Cacciola wrote:
Ha I see... that is 2.6 specific right?
There are still too many 2.4 versions shiped with Linux et al, and we
don't want to ask our users to *manually* upgrade cmake when they
already have one installed, so I'm keeping all compatible with at least
2.4.5
Well, not m
Hi Bill,
So, I guess I will comment on this... :)
:)
Originally CMake was directory based. We are moving towards being
target based. For directories, targets, and projects, there should be
a way to set:
- defines
- includes
- link libraries
- compiler flags
Hard to argue with that :
So, I guess I will comment on this... :)
Originally CMake was directory based. We are moving towards being
target based. For directories, targets, and projects, there should be
a way to set:
- defines
- includes
- link libraries
- compiler flags
Currently you can set:
compiler flags:
h
Hi Colin,
On Tue, 11 Nov 2008 16:13:43 -0200
Fernando Cacciola
<[EMAIL PROTECTED]> wrote:
Hi Andreas,
On 11 Nov 2008 18:12:33 +0100, Andreas Pakulat wrote:
In fact I don't understand why include_directories and
add_definitions are not deprecated as well
Which is precisely my point!! :)
targ
Colin D Bennett schrieb:
> However, I would argue that target_link_libraries vs.
> link_libraries is more important than the possible
> target_include_directories vs. include_directories, since the linked
> libraries will directly affect the generated output (linking to
> unnecessary libraries is w
On Tue, 11 Nov 2008 16:13:43 -0200
Fernando Cacciola
<[EMAIL PROTECTED]> wrote:
> Hi Andreas,
> On 11 Nov 2008 18:12:33 +0100, Andreas Pakulat wrote:
> > In fact I don't understand why include_directories and
> > add_definitions are not deprecated as well
>
> Which is precisely my point!! :)
>
Am Tuesday 11 November 2008 19:13:43 schrieb Fernando Cacciola:
> target_link_libraries, which is GREAT, is actually pretty useless
> without target_include_directories, target_add_definitions and
> _CMAKE_CXX_FLAGS.
Did you notice set_property(TARGET .)? There, you can do add target
specific
On 11.11.08 16:13:43, Fernando Cacciola wrote:
> Which is precisely my point!! :)
>
> target_link_libraries, which is GREAT, is actually pretty useless
> without target_include_directories, target_add_definitions and
> _CMAKE_CXX_FLAGS.
>
> Yet OTOH given that those do not exists, it is just pl
Hi Andreas,
On 11.11.08 14:12:39, Fernando Cacciola wrote:
Hi Andreas,
On 10.11.08 12:01:13, Fernando Cacciola wrote:
The CGAL library (www.cgal.org) uses cmake as build system. Thus, our
users do:
find_package(CGAL REQUIRED)
include( ${CGAL_USE_FILE} )
...
UseCGAL.cmake, as all such fi
On 11.11.08 14:12:39, Fernando Cacciola wrote:
> Hi Andreas,
>
>> On 10.11.08 12:01:13, Fernando Cacciola wrote:
>>> The CGAL library (www.cgal.org) uses cmake as build system. Thus, our
>>> users do:
>>>
>>> find_package(CGAL REQUIRED)
>>> include( ${CGAL_USE_FILE} )
>>> ...
>>>
>>>
>>> UseCGAL.
Hi Andreas,
On 10.11.08 12:01:13, Fernando Cacciola wrote:
The CGAL library (www.cgal.org) uses cmake as build system. Thus, our
users do:
find_package(CGAL REQUIRED)
include( ${CGAL_USE_FILE} )
...
UseCGAL.cmake, as all such files, call include_directories,
add_definitions and overrides
Hi, my 2c...
2008/11/10 Andreas Pakulat <[EMAIL PROTECTED]>
On 10.11.08 12:01:13, Fernando Cacciola wrote:
> The CGAL library (www.cgal.org) uses cmake as build system. Thus, our
> users do:
>
> find_package(CGAL REQUIRED)
> include( ${CGAL_USE_FILE} )
>
>
> There are projects that have headers
On 10.11.08 12:01:13, Fernando Cacciola wrote:
> The CGAL library (www.cgal.org) uses cmake as build system. Thus, our
> users do:
>
> find_package(CGAL REQUIRED)
> include( ${CGAL_USE_FILE} )
> ...
>
>
> UseCGAL.cmake, as all such files, call include_directories,
> add_definitions and override
Hi people,
The CGAL library (www.cgal.org) uses cmake as build system. Thus, our
users do:
find_package(CGAL REQUIRED)
include( ${CGAL_USE_FILE} )
...
UseCGAL.cmake, as all such files, call include_directories,
add_definitions and overrides (under certain circumstances) the
compiler/linker
21 matches
Mail list logo
