Well let's look at how some things are handled.
direct X has multiple version of the same library, and msvcrt
(msvcrtd)... these are name mangled things.
.NET has moved to keeping seperate directories where everything is
exactly the same name.
Surely there's more than one paradigm that can be us
I was trying to cross compile from snow leopard to iphone simulator.
struggled a few days with "file was built for i386 which is not the
architecture being linked (x86_64)".
and found http://www.itk.org/Bug/view.php?id=9466 bug history.
looks like the same bug popped up in 2.8.2 version.
The erro
> I have created a very simple CMake file (I am a newbie) that works
> wonderfully in Linux, but am having problems in Windows. The CMakeLists.txt
> is below
>
> #I think 2.6 is required for some of things I do below, but I am not sure
> CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
>
> # This is the CMake
Hi!
Am 30.07.2010 22:23, schrieb Clark Taylor:
I have created a very simple CMake file (I am a newbie) that works
wonderfully in Linux, but am having problems in Windows. The
CMakeLists.txt is below
#I think 2.6 is required for some of things I do below, but I am not sure
CMAKE_MINIMUM_REQUIR
>
>
> I'm doing something similar, but I hit a problem when adding the
> dependencies
> so that the external projects are actually built.
> The issues is that it is currently not possible to use add_dependencies()
> with
> imported targets, here's the issue for it:
> http://public.kitware.com/Bug/v
I would recommend using EXTERNALPROJECT_ADD.
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#module:ExternalProject.
Though I am not building in ITK as of yet I am using VTKEdge which depends
on VTK
--snip vtkedge_config.cmake --
macro( vtkedge_config )
set( VTK_EDGE_PACKAGE VTKEdge-5-4-0
For removing files, you can use ADDITIONAL_MAKE_CLEAN_FILES:
>From http://www.vtk.org/Wiki/CMake_FAQ:
Running "make clean" does not remove custom command outputs. Why?
In CMake 2.2 and higher custom command outputs should be removed by make clean.
Make sure you are using at least this version. P
Greetings,
I have recently been tasked with converting our old GNU makefiles to CMake
for a medium-sized project involving both C and Fortran external components.
CMake has made a big difference and helped make this process much more
straightforward for each of the researchers who are using differ
I have created a very simple CMake file (I am a newbie) that works
wonderfully in Linux, but am having problems in Windows. The CMakeLists.txt
is below
#I think 2.6 is required for some of things I do below, but I am not sure
CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
# This is the CMake file for my ap
Can a roadmap be posted for CMake? Such as is for other projects at:
http://www.cmake.org/Bug/roadmap_page.php
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep me
you can do...
SET_TARGET_PROPERTIES( PROPERTIES
PREFIX ""
SUFFIX ""
)
well probably the suffix you want to leave as .dll... just copied from
something that makes the library exactly what the target name is.
On Fri, Jul 30, 2010 at 10:54 AM, Jim Peterson
Start here:
http://cmake.org/cmake/help/cmake-2-8-docs.html#variable:CMAKE_SHARED_LIBRARY_PREFIX
On Fri, Jul 30, 2010 at 1:54 PM, Jim Peterson wrote:
> David,
> IMHOP, the naming of the java DLL is dictated by the java behavior on the
> platform, not the compiler in use. Static libraries can be
What is the primary user of a mingw compiler system trying to achieve?
Somebody trying to build unix-y stuff for Windows?
Or somebody trying to build unix-y stuff to still be unix-y in an MSYS shell
environment?
Because the answer is ambiguous, there is no right answer. Therefore, we've
chosen on
David,
IMHOP, the naming of the java DLL is dictated by the java behavior on
the platform, not the compiler in use. Static libraries can be named
with the lib prefix according to the compiler requirements, but runtime
libraries (on windows DLLs) need to be named according to the runtime
users
I could be wrong... I'm not a huge mingw user, but I think this is the
expected library naming for a mingw build.
If so, then the VTK java wrapping code is just not going to work on mingw as
it stands now. I suspect there are few, if any, users of java wrappers using
a mingw build of VTK. If there
Let's keep things calm, reasonable, rational here on the CMake mailing list.
It's a discussion. Some discussions require more patience than others... :-)
Olaf, clearly you have an idea that you are passionate about.
Just as clearly, most of the other responders to this topic have reasons to
be bi
On Friday 30 Jul 2010 3:39:58 pm David Cole wrote:
> Could you elaborate on "full support for multiple components in cpack"
> either in another thread, or in a feature request bug in the bug tracker?
>
> With NSIS on Windows and PackageMaker on Mac, we already have what I would
> consider "full su
On Friday 30 Jul 2010 5:05:56 pm Eric Noulard wrote:
> Hi All,
> I'll try to launch a specific thread for this following what
>
> Kishore said:
> > I would like to see full support for multiple components in cpack.
>
> David answered:
> > Could you elaborate on "full support for multiple componen
David,
I am new to this list and vtk, One point I have noticed is that I have
been unable to correctly generate the Java wrappers for VTK using cmake
and cmake-gui for the windows hosted jvm. I have opened a bug tracker
incident http://public.kitware.com/Bug/view.php?id=10969 which is
current
On Fri, Jul 30, 2010 at 2:58 PM, Michael Jackson
wrote:
> And what if someone else is using a different naming decoration for
> their project than what is in the auto-link headers? Then you have to
> update all those headers to your own naming scheme which amounts to a
> fork of that project. Whic
On 30. Jul, 2010, at 14:46 , Olaf van der Spek wrote:
> On Fri, Jul 30, 2010 at 2:42 PM, Michael Wild wrote:
>> Oh, it IS library specific. Where do you think all these BOOST_MSVC and what
>> not come from? It is very specific to Boost. No other project will be able
>> to use this without heav
On Fri, Jul 30, 2010 at 7:49 AM, Ryan Pavlik wrote:
> On 7/30/10 6:45 AM, Michael Wild wrote:
>>
>> On 30. Jul, 2010, at 13:16 , Olaf van der Spek wrote:
>>
>>> On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild wrote:
First of all: There is almost NO duplication, since almost every project
-
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jack...@bluequartz.net
BlueQuartz Software Dayton, Ohio
On Jul 30, 2010, at 8:46, Olaf van der Spek wrote:
> On Fri, Jul 30, 2010 at 2:42 PM, Michael Wild wrote:
>> Oh, it IS library
On Fri, Jul 30, 2010 at 2:42 PM, Michael Wild wrote:
> Oh, it IS library specific. Where do you think all these BOOST_MSVC and what
> not come from? It is very specific to Boost. No other project will be able to
> use this without heavy reworking.
That's just the MSVC version, available as _MSC
On 30. Jul, 2010, at 14:31 , Olaf van der Spek wrote:
> On Fri, Jul 30, 2010 at 2:25 PM, Michael Wild wrote:
>> Create a module and share it among your projects, possibly with others. If
>> it's any good it might get included in CMake.
>
> I probably will.
>
> On Windows, at least build t
On 30. Jul, 2010, at 14:16 , John Drescher wrote:
>> Please do explain. How would this work? What would the API be? And now it
>> suddenly sounds like CMake isn't supposed to do everything automagically
>> anymore. If that is the case, please RTFM and look into the OUTPUT_NAME
>> target proper
Hi,
With CMake 2.8.2 and Visual Studio 2010, it seems that using compiler
flag property in set_source_files_properties will overwrite the
inherited properties in some cases.
For example, in one cmake project, we have a global setting of include
headers:
include_headers(${global_includ
On Fri, Jul 30, 2010 at 2:25 PM, Michael Wild wrote:
> Create a module and share it among your projects, possibly with others. If
> it's any good it might get included in CMake.
I probably will.
On Windows, at least build type, run-time and platform.
But what should and what should no
On 30. Jul, 2010, at 13:54 , Olaf van der Spek wrote:
> On Fri, Jul 30, 2010 at 1:45 PM, Michael Wild wrote:
>>
>> On 30. Jul, 2010, at 13:16 , Olaf van der Spek wrote:
>>
>>> On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild wrote:
First of all: There is almost NO duplication, since almost
On Fri, Jul 30, 2010 at 2:15 PM, Ryan Pavlik wrote:
>>> The issue conceptually for me here, is that the code shouldn't/doesn't
>>> necessarily know what exact library name to link against - think
>>> different
>>> versions of libraries, different platforms...
>>
>> Could you give a concrete exampl
On Fri, Jul 30, 2010 at 2:11 PM, Ryan Pavlik wrote:
> On 7/30/10 7:01 AM, Olaf van der Spek wrote:
>>
>> On Fri, Jul 30, 2010 at 1:52 PM, Ryan Pavlik wrote:
>>>
>>> Almost nobody uses the static runtime unless someone else's lib forces
>>> them
>>
>> Why not?
>> If Windows had proper package man
> Please do explain. How would this work? What would the API be? And now it
> suddenly sounds like CMake isn't supposed to do everything automagically
> anymore. If that is the case, please RTFM and look into the OUTPUT_NAME
> target property. It offers exactly what you want!
>
Or the prefix va
On 7/30/10 7:11 AM, Olaf van der Spek wrote:
On Fri, Jul 30, 2010 at 2:05 PM, Ryan Pavlik wrote:
It's a shame gcc doesn't support it yet. I would love to see support
there.
Olaf
The issue conceptually for me here, is that the code shouldn't/doesn't
necessarily know what exact library name to
On 7/30/10 7:01 AM, Olaf van der Spek wrote:
On Fri, Jul 30, 2010 at 1:52 PM, Ryan Pavlik wrote:
Almost nobody uses the static runtime unless someone else's lib forces them
Why not?
If Windows had proper package management I wouldn't use it either, but
until then...
Olaf
I'd only really just
On Fri, Jul 30, 2010 at 2:05 PM, Ryan Pavlik wrote:
>> It's a shame gcc doesn't support it yet. I would love to see support
>> there.
>>
>> Olaf
>
> The issue conceptually for me here, is that the code shouldn't/doesn't
> necessarily know what exact library name to link against - think different
>
On 7/30/10 6:58 AM, Olaf van der Spek wrote:
On Fri, Jul 30, 2010 at 1:49 PM, Ryan Pavlik wrote:
And, if you ask any auto*-using developer how they feel about detecting and
configuring boost, prepare for some impolite words. Even the cmake module
for detecting it is complex.
(and auto-linkin
On Fri, Jul 30, 2010 at 1:52 PM, Ryan Pavlik wrote:
> Almost nobody uses the static runtime unless someone else's lib forces them
Why not?
If Windows had proper package management I wouldn't use it either, but
until then...
Olaf
___
Powered by www.kitw
On 7/29/10 5:40 PM, Michael Jackson wrote:
Well luckily there are a whole slew of projects to take a look at.
HDF5 is one. CMake, VTK, ITK, ParaView are some others. Basically you
have a .cmake file that runs all the tests like looking for headers,
structs, functions and stuff like that. Each
On 7/30/10 6:35 AM, Eric Noulard wrote:
Hi All,
I'll try to launch a specific thread for this following what
Kishore said:
I would like to see full support for multiple components in cpack.
David answered:
Could you elaborate on "full support for multiple components in cpack" either
in anot
On Fri, Jul 30, 2010 at 1:49 PM, Ryan Pavlik wrote:
> And, if you ask any auto*-using developer how they feel about detecting and
> configuring boost, prepare for some impolite words. Even the cmake module
> for detecting it is complex.
>
> (and auto-linking appears to only work on windows with M
On Fri, Jul 30, 2010 at 1:45 PM, Ryan Pavlik wrote:
> If you want to avoid code duplication, write a cmake module that does it
> then share it with the world. This doesn't have to be a top-down solution:
> if you think you have the best library decoration system wrapped in a tidy,
> documented mo
On Fri, Jul 30, 2010 at 1:45 PM, Michael Wild wrote:
>
> On 30. Jul, 2010, at 13:16 , Olaf van der Spek wrote:
>
>> On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild wrote:
>>> First of all: There is almost NO duplication, since almost every project
>>> that does decoration uses different convention
On 7/30/10 5:25 AM, Olaf van der Spek wrote:
Hi,
CMake creates a VS project file that uses the dynamic run-time for
static libs. This is not what I want in release builds.
How do I change this?
Greetings,
Olaf
cmake_minimum_required(VERSION 2.4)
set(CMAKE_BUILD_TYPE release)
include_director
On 7/30/10 6:45 AM, Michael Wild wrote:
On 30. Jul, 2010, at 13:16 , Olaf van der Spek wrote:
On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild wrote:
First of all: There is almost NO duplication, since almost every project that
does decoration uses different conventions.
Duplication does not
On 7/30/10 6:16 AM, Olaf van der Spek wrote:
On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild wrote:
First of all: There is almost NO duplication, since almost every project that
does decoration uses different conventions.
Duplication does not mean that the code is 100% equal.
Second: It is i
On 30. Jul, 2010, at 13:16 , Olaf van der Spek wrote:
> On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild wrote:
>> First of all: There is almost NO duplication, since almost every project
>> that does decoration uses different conventions.
>
> Duplication does not mean that the code is 100% equal
Hi All,
I'll try to launch a specific thread for this following what
Kishore said:
> I would like to see full support for multiple components in cpack.
David answered:
> Could you elaborate on "full support for multiple components in cpack" either
> in another thread,
> or in a feature request b
On Fri, Jul 30, 2010 at 9:06 AM, Michael Wild wrote:
> First of all: There is almost NO duplication, since almost every project that
> does decoration uses different conventions.
Duplication does not mean that the code is 100% equal.
> Second: It is impossible for CMake do come up with a good d
On Fri, Jul 30, 2010 at 7:53 AM, Verweij, Arjen wrote:
> Perhaps you should write a proposal that takes care of details, like how you
> would like to see this decorated.
Good idea, as not everyone seems to understand my goals.
> Then write a patch or create a cmake module that takes care of thi
Hi,
CMake creates a VS project file that uses the dynamic run-time for
static libs. This is not what I want in release builds.
How do I change this?
Greetings,
Olaf
cmake_minimum_required(VERSION 2.4)
set(CMAKE_BUILD_TYPE release)
include_directories(.)
add_library(
xbt
sql/data
Could you elaborate on "full support for multiple components in cpack"
either in another thread, or in a feature request bug in the bug tracker?
With NSIS on Windows and PackageMaker on Mac, we already have what I would
consider "full support". Are you talking about extending that to additional
CP
On 30. Jul, 2010, at 7:53 , Verweij, Arjen wrote:
> Olaf,
>
Why?
I'm still waiting for someone to post a reason of why a decorated
name is a problem for them.
Also waiting on an answer to the code duplication issue.
>
> Perhaps you should write a proposal that takes care of
52 matches
Mail list logo
