date:20100730

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 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 requirements.
> also, it appears that the internal logic within the VTK Java wrappers
> expects to load the shared implementation libraries without the lib prefix.
>
> I will see if I can get the visual studio compile put together, but my
> strong suspicion is the output from the VS shared libraries and wrappers is
> a suite of DLL's without the lib prefix, and therefore compatible with the
> Java runtime expectations.
>
> meanwhile, can you let me know which modules establish target library names
> used in the link.txt and build.make outputs? or some point of reference to
> get familiar with the cmake structure that results in the generation of the
> sets of make files? I will see if I can get the files generated with my
> impression of correct DLL names.
> Thanks,
> Jim
>
> David Cole wrote:
>
>> 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 are, they must be patching it
>> somehow...
>>
>> The java wrappers in VTK are the least used (of python, tcl and java), but
>> I do know that they work with Visual Studio builds of VTK. Maybe you could
>> try with a Visual Studio Express build of java-wrapped VTK?
>>
>> Or perhaps other VTK-on-mingw users could chime in here with their own
>> advice.
>>
>> Either way, I do not think 10969 is a CMake bug. I'm going to move it to
>> the VTK project. If I am wrong, and somebody else convinces me otherwise,
>> I'll be happy to move it back later.
>>
>>
>> Hope this helps,
>> David
>>
>>
>> Are there any others
>> On Fri, Jul 30, 2010 at 9:23 AM, Jim Peterson > ji...@cox.net>> wrote:
>>
>>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 currently
>>unassigned. The nature of the problem is the java test programs
>>that use the java statement:
>>System.loadLibrary("vtkCommonJava");
>>fails on my Windows machine with unable to load vtkCommonJava.dll.
>>the superficial reason for this appears to be that the generated
>>make file is creating a dll named libvtkCommonJava.dll. The
>>windows system specific behavior when processing the loadLibrary
>>command only appends dll, it does not prepend lib to the name
>>specified.
>>This naming behavior appears to be true for all shared libraries,
>>so simply renaming libvtkCommonJava.dll to vtkCommonJava.dll
>>results in a failure to load vtkCommon.dll during the vtk Java dll
>>initialization.
>>
>>I am not completely versed in the specifications for cmake, if
>>there is some option that can effect this behavior and correct the
>>shared library naming rules I would be happy to use it
>>
>>Thanks for your patience with me as I learn this tool,
>>Jim Peterson
>>
>>
>>
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] mingw library naming - bug 10969

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 one... which in this particular case is not yielding the correct
result.

Hopefully, the CMAKE_SHARED_LIBRARY_PREFIX can be set for VTK, and you can
get the result you're looking for.


HTH,
David


On Fri, Jul 30, 2010 at 2:19 PM, David Cole  wrote:

> 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 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 requirements.
>> also, it appears that the internal logic within the VTK Java wrappers
>> expects to load the shared implementation libraries without the lib prefix.
>>
>> I will see if I can get the visual studio compile put together, but my
>> strong suspicion is the output from the VS shared libraries and wrappers is
>> a suite of DLL's without the lib prefix, and therefore compatible with the
>> Java runtime expectations.
>>
>> meanwhile, can you let me know which modules establish target library
>> names used in the link.txt and build.make outputs? or some point of
>> reference to get familiar with the cmake structure that results in the
>> generation of the sets of make files? I will see if I can get the files
>> generated with my impression of correct DLL names.
>> Thanks,
>> Jim
>>
>> David Cole wrote:
>>
>>> 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 are, they must be patching it
>>> somehow...
>>>
>>> The java wrappers in VTK are the least used (of python, tcl and java),
>>> but I do know that they work with Visual Studio builds of VTK. Maybe you
>>> could try with a Visual Studio Express build of java-wrapped VTK?
>>>
>>> Or perhaps other VTK-on-mingw users could chime in here with their own
>>> advice.
>>>
>>> Either way, I do not think 10969 is a CMake bug. I'm going to move it to
>>> the VTK project. If I am wrong, and somebody else convinces me otherwise,
>>> I'll be happy to move it back later.
>>>
>>>
>>> Hope this helps,
>>> David
>>>
>>>
>>> Are there any others
>>> On Fri, Jul 30, 2010 at 9:23 AM, Jim Peterson >> ji...@cox.net>> wrote:
>>>
>>>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 currently
>>>unassigned. The nature of the problem is the java test programs
>>>that use the java statement:
>>>System.loadLibrary("vtkCommonJava");
>>>fails on my Windows machine with unable to load vtkCommonJava.dll.
>>>the superficial reason for this appears to be that the generated
>>>make file is creating a dll named libvtkCommonJava.dll. The
>>>windows system specific behavior when processing the loadLibrary
>>>command only appends dll, it does not prepend lib to the name
>>>specified.
>>>This naming behavior appears to be true for all shared libraries,
>>>so simply renaming libvtkCommonJava.dll to vtkCommonJava.dll
>>>results in a failure to load vtkCommon.dll during the vtk Java dll
>>>initialization.
>>>
>>>I am not completely versed in the specifications for cmake, if
>>>there is some option that can effect this behavior and correct the
>>>shared library naming rules I would be happy to use it
>>>
>>>Thanks for your patience with me as I learn this tool,
>>>Jim Peterson
>>>
>>>
>>>
>>
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] mingw library naming - bug 10969

2010-07-30 Thread Jim Peterson


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 requirements. also, it appears that the internal logic within the 
VTK Java wrappers expects to load the shared implementation libraries 
without the lib prefix.


I will see if I can get the visual studio compile put together, but my 
strong suspicion is the output from the VS shared libraries and wrappers 
is a suite of DLL's without the lib prefix, and therefore compatible 
with the Java runtime expectations.


meanwhile, can you let me know which modules establish target library 
names used in the link.txt and build.make outputs? or some point of 
reference to get familiar with the cmake structure that results in the 
generation of the sets of make files? I will see if I can get the files 
generated with my impression of correct DLL names.   


Thanks,
Jim

David Cole wrote:
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 are, they must be 
patching it somehow...


The java wrappers in VTK are the least used (of python, tcl and java), 
but I do know that they work with Visual Studio builds of VTK. Maybe 
you could try with a Visual Studio Express build of java-wrapped VTK?


Or perhaps other VTK-on-mingw users could chime in here with their own 
advice.


Either way, I do not think 10969 is a CMake bug. I'm going to move it 
to the VTK project. If I am wrong, and somebody else convinces me 
otherwise, I'll be happy to move it back later.



Hope this helps,
David


Are there any others
On Fri, Jul 30, 2010 at 9:23 AM, Jim Peterson > wrote:


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 currently
unassigned. The nature of the problem is the java test programs
that use the java statement:
System.loadLibrary("vtkCommonJava");
fails on my Windows machine with unable to load vtkCommonJava.dll.
the superficial reason for this appears to be that the generated
make file is creating a dll named libvtkCommonJava.dll. The
windows system specific behavior when processing the loadLibrary
command only appends dll, it does not prepend lib to the name
specified.
This naming behavior appears to be true for all shared libraries,
so simply renaming libvtkCommonJava.dll to vtkCommonJava.dll
results in a failure to load vtkCommon.dll during the vtk Java dll
initialization.

I am not completely versed in the specifications for cmake, if
there is some option that can effect this behavior and correct the
shared library naming rules I would be happy to use it

Thanks for your patience with me as I learn this tool,
Jim Peterson




___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] mingw library naming - bug 10969

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 are, they must be patching it somehow...

The java wrappers in VTK are the least used (of python, tcl and java), but I
do know that they work with Visual Studio builds of VTK. Maybe you could try
with a Visual Studio Express build of java-wrapped VTK?

Or perhaps other VTK-on-mingw users could chime in here with their own
advice.

Either way, I do not think 10969 is a CMake bug. I'm going to move it to the
VTK project. If I am wrong, and somebody else convinces me otherwise, I'll
be happy to move it back later.

Hope this helps,
David

Are there any others
On Fri, Jul 30, 2010 at 9:23 AM, Jim Peterson  wrote:

> 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 currently
> unassigned. The nature of the problem is the java test programs that use the
> java statement:
> System.loadLibrary("vtkCommonJava");
> fails on my Windows machine with unable to load vtkCommonJava.dll.
> the superficial reason for this appears to be that the generated make file
> is creating a dll named libvtkCommonJava.dll. The windows system specific
> behavior when processing the loadLibrary command only appends dll, it does
> not prepend lib to the name specified.
> This naming behavior appears to be true for all shared libraries, so simply
> renaming libvtkCommonJava.dll to vtkCommonJava.dll results in a failure to
> load vtkCommon.dll during the vtk Java dll initialization.
>
> I am not completely versed in the specifications for cmake, if there is
> some option that can effect this behavior and correct the shared library
> naming rules I would be happy to use it
>
> Thanks for your patience with me as I learn this tool,
> Jim Peterson
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] libraryname decoration

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 biased against the idea of automatic library name decoration.

Here are the facts, as I see them:
- It would be possible to add automatic opt-in (not enabled by default)
library name decoration rules to CMake
- It would NOT be possible to come up with a naming scheme that is
acceptable to everyone
- Some people love auto-linking from header files, some people hate it

- If the CMake team were to implement such a feature:
-- it would save Olaf from having to do it himself
-- it would take the CMake team a boat-load of time and money and effort to
implement the feature

For those reasons, I do not see this feature happening anytime soon unless
somebody steps up to the plate with:
- a reasonable design for it, acceptable by the consensus of folks right
here on this mailing list
- an implementation patch, fully tested **or** a contract with somebody
(Kitware, cough, cough) to pay them to implement it

I truly hope this clarifies things for you Olaf.

It's not that we are absolutely opposed to such a feature. But please
recognize that it's a large amount of effort to implement it, make sure it's
tested and works on all platforms, and keep it working moving forward.
Especially hard to achieve without consensus...


Thanks,
David Cole
Kitware, Inc.


On Fri, Jul 30, 2010 at 9:08 AM, Michael Wild  wrote:

>
> 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 heavy reworking.
> >
> > That's just the MSVC version, available as _MSC_VER by default.
>
> Oh bugger, you really are immune to reason...
>
> 1. This is not the only macro.
> 2. A library project wanting to distribute a similar file has to do a lot
> of work to adapt it to its own requirements.
> 3. It is a maintenance nightmare, because e.g. _MSC_VER is combined from
> the major and minor version number of the compiler, so for VS 2010 it is
> 1600. This requires that for every new version you'll be adding a new branch
> in the #if ... #elif ... #endif maze, translating that number into a
> readable name. Now, imagine other compilers starting to adopt this "magic",
> this file would just explode (and compilation would probably slow down to a
> crawl).
>
> >
>  For every new version of MSVC, Xcode etc. you have to update the file.
> Usually you will be lagging behind, and your users even more so. And then
> they will complain. To you.
> >
> > Only if you include the toolset in the name.
>
> This is really wearing my patience right now. I suggest we stop this
> absolutely futile discussion and let Olaf come up with something
> constructive for once (such as a patch). At least I will.
>
> Michael
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Bug fix requests for the next release of CMake...

2010-07-30 Thread Kishore

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 support". Are you talking about extending that to additional
> CPack generators or is there something missing even in those generators in
> your opinion?

At the very basic level, i wish to see equal support for the other generators. 
Especially DEB and RPM. For the more advanced, like dependency between 
components, i would first need to check the level of support in NSIS. 
Nevertheless, DEB and RPM can benefit from inter component dependencies.

> 
> Thanks,
> David
> 
> On Fri, Jul 30, 2010 at 1:02 AM, Kishore 
wrote:
> > I would like to see full support for multiple components in cpack.
> > 
> > On Tuesday 06 Jul 2010 12:01:17 am David Cole wrote:
> > > Hi all,
> > > 
> > > Now that we have released CMake 2.8.2 last Monday, and we have switched
> > 
> > to
> > 
> > > this new workflow using branches in the git repository, *now* would be
> > > a great time to prioritize bug fixes for the next release of CMake.
> > > 
> > > We are leaning towards quarterly releases from now on, scheduling them
> > > every 3 months. That would make the next release of CMake version 2.8.3
> > > and scheduled to have an "rc1" release candidate in approximately
> > > mid-September, 2010.
> > > 
> > > If you have a particular issue that you think should be fixed for
> > 
> > inclusion
> > 
> > > in 2.8.3, please bring it up now. Ideally, each issue will be discussed
> > 
> > as
> > 
> > > needed on the mailing list to come to any consensus about what should
> > > be done to fix it, and then an entry in the bug tracker may be used to
> > > keep
> > 
> > it
> > 
> > > on the radar screen, and to track activity related to it.
> > > 
> > > Patches are always welcome. Patches that include testing of any new
> > > features, or tests that prove a bug is really fixed on the dashboards,
> > > basically any patch with testing is preferred over a patch with no
> > 
> > testing.
> > 
> > > Also, if you are *adding* code, then you also probably need to add
> > 
> > *tests*
> > 
> > > of that code, so that the coverage percentage stays as is or rises.
> > > 
> > > Please discuss issues here as needed, and add notes to existing issues
> > > in the bug tracker that you are interested in seeing fixed for 2.8.3
> > > -- we will be looking at the mailing list and activity in the bug
> > > tracker to help prioritize the bug fixes that will occur in the next
> > > several weeks.
> > > 
> > > 
> > > Thanks,
> > > David Cole
> > > Kitware, Inc.
> > 
> > --
> > Cheers!
> > Kishore
> > ___
> > Powered by www.kitware.com
> > 
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> > 
> > Please keep messages on-topic and check the CMake FAQ at:
> > http://www.cmake.org/Wiki/CMake_FAQ
> > 
> > Follow this link to subscribe/unsubscribe:
> > http://www.cmake.org/mailman/listinfo/cmake

-- 
Cheers!
Kishore
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Support for multiple components in cpack

2010-07-30 Thread Kishore

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 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 CPack generators or is there something missing even in those
> > generators in your opinion?
> 
> An explanation on CPack Component may be found here:
>http://www.itk.org/Wiki/CMake:Component_Install_With_CPack
> 
> As David said currently the only 2 CPack generators which support
> Components are - NSIS
>- PackageMaker
> 
> I personally would like a wider support including RPM, DEB, TGZ (and
> may be ZIP and other archive-like).
> There is at least one bug/feature report/request for that for  CPackRPM:
> http://public.kitware.com/Bug/view.php?id=7645

Yes. This is what i mean by "full support". As a debian user, i am personally 
most attached to the DEB generator and RPM too. I have not used the NSIS 
installer for anything but the basic, so i am not sure of the level of support 
it has. But by emphasizing the DEB and RPM i also what to state that it should 
take care of dependencies between components. Like for example, If i want to 
install the component for runtime executables, it should have a dependency on 
and hence automatically install the libraries too.

Dependency information could be either explicit or implicit. Implicit would be 
the dependency between the "executables" and the "libraries" components and 
explicit could the dependency of the "headers" component on the "libraries" 
component which would need to be declared in the CMakeLists.txt file.

> From my point of view for the RPM/DEB/archive (TBZ2  TGZ   TZZIP)
> COMPONENT installer there is two "global" options:
> 
> A) Put all the components in a single archive with some hierarchical
> structure inside
> i.e. build a TGZ   whose structure may be;
>   toplevel-name/component1/...
>   /component2/...
>   etc...
> 
> B) Build as many files as components.
>  toplevel-name-component1.tgz
>  toplevel-name-component2.tgz
>  toplevel-name-component3.tgz
> 
> The scheme A) is not quite usable for RPM or DEB
> but it is ok for "pure" archive like TBZ2 , TGZ, TZ,  ZIP.

Indeed. I opt for B.

> My **personal** opinion is that for this kind of installers I'd rather
> go for B).
> The current problem with B) is that current  CPack architecture does
> not authorize it see:
> http://public.kitware.com/Bug/view.php?id=10736
> 
> Like I said in another mail if we tackle the "multiple file problem" we
> should be able to solve the "naming convention problem" too, see:
> http://public.kitware.com/Bug/view.php?id=9900
> 
> So I would like those 2 bugs (9900, 10736)
> solved, which would enable the may-be-easy creation
> of full support for CPack COMPONENTs in any case (including bug 7645).
> 
> Please comment on those ideas or indicate whether if you agree with my
> analysis or not.
> Once we have some opinions ideas on this, I'll propose a new/updated
> API for CPack generators
> concerning this.

-- 
Cheers!
Kishore
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Bug fix requests for the next release of CMake...

2010-07-30 Thread Jim Peterson


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 
currently unassigned. The nature of the problem is the java test 
programs that use the java statement:

System.loadLibrary("vtkCommonJava");
fails on my Windows machine with unable to load vtkCommonJava.dll.
the superficial reason for this appears to be that the generated make 
file is creating a dll named libvtkCommonJava.dll. The windows system 
specific behavior when processing the loadLibrary command only appends 
dll, it does not prepend lib to the name specified.
This naming behavior appears to be true for all shared libraries, so 
simply renaming libvtkCommonJava.dll to vtkCommonJava.dll results in a 
failure to load vtkCommon.dll during the vtk Java dll initialization.


I am not completely versed in the specifications for cmake, if there is 
some option that can effect this behavior and correct the shared library 
naming rules I would be happy to use it


Thanks for your patience with me as I learn this tool,
Jim Peterson
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] libraryname decoration

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. Which sucks.

Why would you change the naming scheme of your dependencies?
You could just disable auto linking and you're back at where you are now.

Olaf
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] libraryname decoration

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 heavy reworking.
> 
> That's just the MSVC version, available as _MSC_VER by default.

Oh bugger, you really are immune to reason...

1. This is not the only macro.
2. A library project wanting to distribute a similar file has to do a lot of 
work to adapt it to its own requirements.
3. It is a maintenance nightmare, because e.g. _MSC_VER is combined from the 
major and minor version number of the compiler, so for VS 2010 it is 1600. This 
requires that for every new version you'll be adding a new branch in the #if 
... #elif ... #endif maze, translating that number into a readable name. Now, 
imagine other compilers starting to adopt this "magic", this file would just 
explode (and compilation would probably slow down to a crawl).

> 
 For every new version of MSVC, Xcode etc. you have to update the file. 
 Usually you will be lagging behind, and your users even more so. And then 
 they will complain. To you.
> 
> Only if you include the toolset in the name.

This is really wearing my patience right now. I suggest we stop this absolutely 
futile discussion and let Olaf come up with something constructive for once 
(such as a patch). At least I will.

Michael
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] libraryname decoration

2010-07-30 Thread Michael Jackson

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
 that does decoration uses different conventions.
>>>
>>> Duplication does not mean that the code is 100% equal.
>>
>> Let's turn this around for once *evilgrin*: Why?
>>
 Second: It is impossible for CMake do come up with a good decoration
 scheme that covers all possible variations.
>>>
>>> Why would this optional scheme have to cover every possible variation?
>>> It's like you're saying that because something can't be done
>>> perfectly, nothing should be done at all.
>>
>> See, there you say it yourself. CMake has already the scheme of adding a
>> debug suffix. Not perfect, but it's there and it is working. Stop whining
>> and provide a patch.
>>
 What criteria should enter the decoration? CMake currently chooses only
 to offer automatic decoration for debug builds, which is IMHO a valid
 choice. Everything else becomes guesswork. Here a list of possible criteria
 that sprang to mind, some of which CMake cannot possibly determine:

 * build-type (debug, release, release with debug info, etc.)
 * 32/64-bit
 * compiler suite (e.g. VS{6,7,8,9,10}, Borland, gcc-4.{0..5}, ...)
 * SDK (e.g. on Mac) or runtime library on Windows
 * single/multi-threaded
 * integer size (e.g. for array indices, see Intel MKL)
>>>
>>> Isn't this defined by ABI, just like 32/64 bit?
>>
>> Not necessarily. The MKL offers the choice of using 32 bit integers
>> (maximum compatibility) and 64 bit integers (huge arrays).
>>
>> This is a rather dated/historic document, but it describes the various
>> models.
>> http://www.unix.org/version2/whatsnew/lp64_wp.html
>>
>> The MKL supports both, ILP64 and LP64, see this:
>>
>> http://www.intel.com/software/products/mkl/docs/linux/WebHelp/mkl_ug_structure/support_for_ilp64_programming.htm
>>
 * license differences (e.g. containing non-free code or DFSG-clean)
 * capabilities, such as using ncurses, GNU readline or BSD editline
 (VERY different),
  using cryptographic software or not (e.g. openssl/gnutls)
>>>
>>> On Windows, at least build type, run-time and platform.
>>> But what should and what should not be part of the name doesn't have
>>> to be fixed. So that's no problem.
>>
>> 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!
>>
 The list goes on and on, and you simply can't expect CMake to make the
 right choice for you (well, it could, but then you would get names that
 easily exceed the maximum length for filenames of almost any operating
 system around and linking against that library without CMake would be utter
 pain).
>>>
>>> MSVC supports auto linking and Boost shows that using it is even
>>> easier then normal linking.
>>
>> Why? (See how annoying this is? Normally I expect this kind of
>> argumentation/questioning from 4-5 year olds...)
>>
>> To answer partially why I don't think that the boost-way is a solution for
>> every project, just look at how it's implemented.
>> http://svn.boost.org/svn/boost/trunk/boost/config/auto_link.hpp
>>
>> Really cool... THAT's a lot of code that requires a lot of maintenance!
>>
>> Michael
>
> 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 MSVC, and I'm not
> prepared to let #pragma comment(lib, "mylib.lib") surrounded by ifdefs sneak
> into my source code.)
>
> --
> Ryan Pavlik
> Human-Computer Interaction Graduate Student
> Virtual Reality Applications Center
> Iowa State University
>
> rpav...@iastate.edu
> http://academic.cleardefinition.com/

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. Which sucks.

Mike Jackson.
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] libraryname decoration

2010-07-30 Thread Michael Jackson

-
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 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_VER by default.
>
 For every new version of MSVC, Xcode etc. you have to update the file. 
 Usually you will be lagging behind, and your users even more so. And then 
 they will complain. To you.
>
> Only if you include the toolset in the name.
>
> Olaf
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] libraryname decoration

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_VER by default.

>>> For every new version of MSVC, Xcode etc. you have to update the file. 
>>> Usually you will be lagging behind, and your users even more so. And then 
>>> they will complain. To you.

Only if you include the toolset in the name.

Olaf
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] libraryname decoration


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 type, run-time and platform.
> But what should and what should not be part of the name doesn't have
> to be fixed. So that's no problem.
 
 Please do explain. How would this work? What would the API be?
>>> 
>>> I don't know yet.
>> 
>> So, how is it no problem then?
> 
> Because I'm quite sure it can be solved.

*sigh*.

> 
 Why? (See how annoying this is? Normally I expect this kind of 
 argumentation/questioning from 4-5 year olds...)
>>> 
>>> Because I don't have to specify the libs to link against myself.
>> 
>> Yes, you do. Because most people library authors will just refuse to write 
>> and maintain an auto_link.hpp
> 
> The auto_link you quoted is not library-specific. But it seems you
> understand why code duplication is bad.
> So there's no need to maintain such an auto_link file.

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.

> 
>> For every new version of MSVC, Xcode etc. you have to update the file. 
>> Usually you will be lagging behind, and your users even more so. And then 
>> they will complain. To you.
> 
> See above.

See below (that doesn't need more explanation...)

//
// select toolset if not defined already:
//
#ifndef BOOST_LIB_TOOLSET
// Note: no compilers before 1200 are supported
#if defined(BOOST_MSVC) && (BOOST_MSVC < 1300)

#  ifdef UNDER_CE
 // vc6:
#define BOOST_LIB_TOOLSET "evc4"
#  else
 // vc6:
#define BOOST_LIB_TOOLSET "vc6"
#  endif

#elif defined(BOOST_MSVC) && (BOOST_MSVC == 1300)

   // vc7:
#  define BOOST_LIB_TOOLSET "vc7"

#elif defined(BOOST_MSVC) && (BOOST_MSVC == 1310)

   // vc71:
#  define BOOST_LIB_TOOLSET "vc71"

#elif defined(BOOST_MSVC) && (BOOST_MSVC == 1400)

   // vc80:
#  define BOOST_LIB_TOOLSET "vc80"

#elif defined(BOOST_MSVC) && (BOOST_MSVC == 1500)

   // vc90:
#  define BOOST_LIB_TOOLSET "vc90"

#elif defined(BOOST_MSVC) && (BOOST_MSVC >= 1600)

   // vc10:
#  define BOOST_LIB_TOOLSET "vc100"

#elif defined(__BORLANDC__)

   // CBuilder 6:
#  define BOOST_LIB_TOOLSET "bcb"

#elif defined(__ICL)

   // Intel C++, no version number:
#  define BOOST_LIB_TOOLSET "iw"

#elif defined(__MWERKS__) && (__MWERKS__ <= 0x31FF )

   // Metrowerks CodeWarrior 8.x
#  define BOOST_LIB_TOOLSET "cw8"

#elif defined(__MWERKS__) && (__MWERKS__ <= 0x32FF )

   // Metrowerks CodeWarrior 9.x
#  define BOOST_LIB_TOOLSET "cw9"

#endif
#endif // BOOST_LIB_TOOLSET


Michael

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] libraryname decoration


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 property. It offers exactly what you want!
>> 
> 
> Or the prefix variables.
> 
> I have the following in a file called NamingConvention.cmake.
> 
> IF(MSVC)
>   
>   IF(MSVC90)
>   SET(CMAKE_DEBUG_POSTFIX "_d_2008")
>   SET(CMAKE_RELEASE_POSTFIX "_2008")
>   SET(CMAKE_RELWITHDEBINFO_POSTFIX "_2008")
>   ENDIF(MSVC90)
>   
>   IF(MSVC80)
>   SET(CMAKE_DEBUG_POSTFIX "_d_2005")
>   SET(CMAKE_RELEASE_POSTFIX "_2005")
>   SET(CMAKE_RELWITHDEBINFO_POSTFIX "_2005")
>   ENDIF(MSVC80)
>   
>   IF(MSVC71)
>   SET(CMAKE_DEBUG_POSTFIX "_d_2003")
>   SET(CMAKE_RELEASE_POSTFIX "_2003")
>   SET(CMAKE_RELWITHDEBINFO_POSTFIX "_2003")
>   ENDIF(MSVC71)
>   
>   IF(MSVC70)
>   SET(CMAKE_DEBUG_POSTFIX "_d_2002")
>   SET(CMAKE_RELEASE_POSTFIX "_2002")
>   SET(CMAKE_RELWITHDEBINFO_POSTFIX "_2002")
>   ENDIF(MSVC70)
>   
>   IF(MSVC60)
>   SET(CMAKE_DEBUG_POSTFIX "_d_vc6")
>   SET(CMAKE_RELEASE_POSTFIX "_vc6")
>   SET(CMAKE_RELWITHDEBINFO_POSTFIX "_vc6")
>   ENDIF(MSVC60)
>   
>   #Name 64bit libaraies differenly
>   IF(CMAKE_SIZEOF_VOID_P MATCHES 8)
>   SET(CMAKE_DEBUG_POSTFIX "${CMAKE_DEBUG_POSTFIX}_x64")
>   SET(CMAKE_RELEASE_POSTFIX "${CMAKE_RELEASE_POSTFIX}_x64")
>   SET(CMAKE_RELWITHDEBINFO_POSTFIX 
> "${CMAKE_RELWITHDEBINFO_POSTFIX}_x64")
>   
>   IF(DETECT_64BIT_PORTABILITY)
>   SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /Wp64")
>   ENDIF(DETECT_64BIT_PORTABILITY)
>   ENDIF(CMAKE_SIZEOF_VOID_P MATCHES 8)
>   
> ENDIF(MSVC)
> 
> To activate the naming convention for any of my projects I just call
> include(CMake\NamingConvention.cmake) in the top of my CMakeLists.txt
> and my libraries all have decorated names that distinguish between
> compiler name and 32/64 bit. If I wanted I could spend 5 minutes and
> add gcc and other defined compilers to this.
> 
> John

Thanks, finally. Olaf, do you see how simple it is? And this code could be 
shortened by a mile:

if(MSVC90)
  set(comp_suffix _2008)
elseif(MSVC80)
  set(comp_suffix _2005)
elseif(MSVC71)
  set(comp_suffix _2003)
elseif(MSVC70)
  set(comp_suffix _2002)
elseif(MSVC60)
  set(comp_suffix _vc6)
endif()
set(arch_suffix)
if(CMAKE_SIZEOF_VOID_P EQUAL 8)
  set(arch_suffix _x64)
  # THIS IS SPECIFIC TO JOHN'S PROJECT
  if(DETECT_64BIT_PORTABILITY)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /Wp64")
  endif()
endif()
set(CMAKE_DEBUG_POSTFIX  _d${comp_suffix}${arch_suffix})
set(CMAKE_RELEASE_POSTFIX  ${comp_suffix}${arch_suffix})
set(CMAKE_RELWITHDEBINFO_POSTFIX   ${comp_suffix}${arch_suffix})
set(CMAKE_MINSIZEREL_POSTFIX   ${comp_suffix}${arch_suffix})

You can extend this to your hearts content...
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] compiler flag property overwriting parents' settings in VS 2010

2010-07-30 Thread Shiqing Fan


 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_include_path})

for some of the source files in this project, we have:

set_source_files_properties(source1.c PROPERTIES COMPILE_FLAGS 
"/I${local_include_path}")


with this settings, we want source1.c have both ${global_include_path} 
and ${local_include_path} included, this is only possible with Visual 
Studio 2008, but not Visual Studio 2010, ${global_include_path} is not 
inherited for source1.c, I have to manually change the property of 
source1.c in VS 2010.


It says in CMake document, for set_source_files_properties command : 
"COMPILE_FLAGS (string) is passed to the compiler as additional command 
line arguments when the source file is compiled. " But it's not true for 
me in Visual Studio 2010. The "additional command line arguments" is 
overwriting the inherited ones.


I don't know if this has been posted or not, I didn't find any solution 
for this. Does any one know how can I solve this problem? Thanks a lot.



Shiqing


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] libraryname decoration

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 not be part of the name doesn't have
 to be fixed. So that's no problem.
>>>
>>> Please do explain. How would this work? What would the API be?
>>
>> I don't know yet.
>
> So, how is it no problem then?

Because I'm quite sure it can be solved.

>>> Why? (See how annoying this is? Normally I expect this kind of 
>>> argumentation/questioning from 4-5 year olds...)
>>
>> Because I don't have to specify the libs to link against myself.
>
> Yes, you do. Because most people library authors will just refuse to write 
> and maintain an auto_link.hpp

The auto_link you quoted is not library-specific. But it seems you
understand why code duplication is bad.
So there's no need to maintain such an auto_link file.

> For every new version of MSVC, Xcode etc. you have to update the file. 
> Usually you will be lagging behind, and your users even more so. And then 
> they will complain. To you.

See above.

Olaf
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] libraryname decoration


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 every project 
 that does decoration uses different conventions.
>>> 
>>> Duplication does not mean that the code is 100% equal.
>> 
>> Let's turn this around for once *evilgrin*: Why?
> 
> If the code is 100% equal there's no problem. Problems arise when you
> alter one copy but forget to alter other copies. At that point there's
> inconsistency.

Create a module and share it among your projects, possibly with others. If it's 
any good it might get included in CMake.

Although, I suspect that what you want either requires wrapping add_library and 
add_executable in custom functions or heavy modifications to 
cmTarget::GetFullNameInternal().

> 
>>> On Windows, at least build type, run-time and platform.
>>> But what should and what should not be part of the name doesn't have
>>> to be fixed. So that's no problem.
>> 
>> Please do explain. How would this work? What would the API be?
> 
> I don't know yet.

So, how is it no problem then?

> 
>> 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!

...

>> 
>>> 
 The list goes on and on, and you simply can't expect CMake to make the 
 right choice for you (well, it could, but then you would get names that 
 easily exceed the maximum length for filenames of almost any operating 
 system around and linking against that library without CMake would be 
 utter pain).
>>> 
>>> MSVC supports auto linking and Boost shows that using it is even
>>> easier then normal linking.
>> 
>> Why? (See how annoying this is? Normally I expect this kind of 
>> argumentation/questioning from 4-5 year olds...)
> 
> Because I don't have to specify the libs to link against myself.

Yes, you do. Because most people library authors will just refuse to write and 
maintain an auto_link.hpp

> 
>> To answer partially why I don't think that the boost-way is a solution for 
>> every project, just look at how it's implemented.
>> http://svn.boost.org/svn/boost/trunk/boost/config/auto_link.hpp
>> 
>> Really cool... THAT's a lot of code that requires a lot of maintenance!
> 
> Why?
> Yes, it's a lot of code, but why does that imply it requires a lot of
> maintenance?

For every new version of MSVC, Xcode etc. you have to update the file. Usually 
you will be lagging behind, and your users even more so. And then they will 
complain. To you.

Michael

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] libraryname decoration

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 example? As, again with Boost, I've never
>> seen an issue like this.
>
> see starting at line 272
> http://github.com/rpavlik/vrpn/blob/master/vrpn_Configure.h

I see sometimes you're using a release lib in a debug build.
If that's required, not using auto linking seems like a good option.

>>> What ends up happening in
>>> projects that rely on those kinds of constructs, is your config system
>>> ends
>>> up having to configure a file specifying the library names for the
>>> pragmas
>>> to work, which ends up being more hassle than just handling linking
>>> entirely
>>> within the build system.  (Plus, then you get the whole "I know exactly
>>> what
>>> my project links against and uses" benefit.)
>>> I use boost a lot.  I've only used its auto-linking by accident, when it
>>> guesses the wrong decorated name or wrong location for my platform, at
>>> which
>>> point I realize I missed a library in my build system.  It ends up being
>>> a
>>> slightly more convenient "unresolved symbols" error.
>>
>> Interesting. What was the cause of this issue?
>>
>> Olaf
>
> Exactly what I said: when I failed to realize I needed to link a library for
> one of the boost modules I was using.
> (If you use the deprecated link_directories command you might not notice
> this as often, but I've learned that it's the wrong thing to do and that
> full library paths passed to the linker are the most reliable.)

So you disabled auto linking and then failed to link it manually?
How's that a failure of Boost auto linking?

Olaf
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [VS] How to set static run-time for static lib release config?

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 management I wouldn't use it either, but
>> until then...
>>
>> Olaf
>
> I'd only really just offer it as one option, in case a user of your library
> is forced to use another library with the static runtime.  It doesn't mean
> that you don't have a static library without it, it just means you aren't
> embedding the entire standard c/c++ runtime library into yours, bloating
> memory usage, and inviting lots of symbol collisions when versions don't
> quite match.  Myself and my colleagues have collectively lost significant
> hair on this one, and it took a while for me to figure out exactly what it
> all meant since it's kind of confusing. (and the error messages more so)

That's why I'm asking for library names to be decorated!
So one can choose and know whether a library is using the run-time in
a static way or in a dynamic way.

Olaf
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] libraryname decoration

2010-07-30 Thread John Drescher

> 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 variables.

I have the following in a file called NamingConvention.cmake.

IF(MSVC)

IF(MSVC90)
SET(CMAKE_DEBUG_POSTFIX "_d_2008")
SET(CMAKE_RELEASE_POSTFIX "_2008")
SET(CMAKE_RELWITHDEBINFO_POSTFIX "_2008")
ENDIF(MSVC90)

IF(MSVC80)
SET(CMAKE_DEBUG_POSTFIX "_d_2005")
SET(CMAKE_RELEASE_POSTFIX "_2005")
SET(CMAKE_RELWITHDEBINFO_POSTFIX "_2005")
ENDIF(MSVC80)

IF(MSVC71)
SET(CMAKE_DEBUG_POSTFIX "_d_2003")
SET(CMAKE_RELEASE_POSTFIX "_2003")
SET(CMAKE_RELWITHDEBINFO_POSTFIX "_2003")
ENDIF(MSVC71)

IF(MSVC70)
SET(CMAKE_DEBUG_POSTFIX "_d_2002")
SET(CMAKE_RELEASE_POSTFIX "_2002")
SET(CMAKE_RELWITHDEBINFO_POSTFIX "_2002")
ENDIF(MSVC70)

IF(MSVC60)
SET(CMAKE_DEBUG_POSTFIX "_d_vc6")
SET(CMAKE_RELEASE_POSTFIX "_vc6")
SET(CMAKE_RELWITHDEBINFO_POSTFIX "_vc6")
ENDIF(MSVC60)

#Name 64bit libaraies differenly
IF(CMAKE_SIZEOF_VOID_P MATCHES 8)
SET(CMAKE_DEBUG_POSTFIX "${CMAKE_DEBUG_POSTFIX}_x64")
SET(CMAKE_RELEASE_POSTFIX "${CMAKE_RELEASE_POSTFIX}_x64")
SET(CMAKE_RELWITHDEBINFO_POSTFIX 
"${CMAKE_RELWITHDEBINFO_POSTFIX}_x64")

IF(DETECT_64BIT_PORTABILITY)
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /Wp64")
ENDIF(DETECT_64BIT_PORTABILITY)
ENDIF(CMAKE_SIZEOF_VOID_P MATCHES 8)

ENDIF(MSVC)

To activate the naming convention for any of my projects I just call
include(CMake\NamingConvention.cmake) in the top of my CMakeLists.txt
and my libraries all have decorated names that distinguish between
compiler name and 32/64 bit. If I wanted I could spend 5 minutes and
add gcc and other defined compilers to this.

John
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] libraryname decoration


 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 link against - think different
versions of libraries, different platforms...

Could you give a concrete example? As, again with Boost, I've never
seen an issue like this.
see starting at line 272 
http://github.com/rpavlik/vrpn/blob/master/vrpn_Configure.h



What ends up happening in
projects that rely on those kinds of constructs, is your config system ends
up having to configure a file specifying the library names for the pragmas
to work, which ends up being more hassle than just handling linking entirely
within the build system.  (Plus, then you get the whole "I know exactly what
my project links against and uses" benefit.)
I use boost a lot.  I've only used its auto-linking by accident, when it
guesses the wrong decorated name or wrong location for my platform, at which
point I realize I missed a library in my build system.  It ends up being a
slightly more convenient "unresolved symbols" error.

Interesting. What was the cause of this issue?

Olaf
Exactly what I said: when I failed to realize I needed to link a library 
for one of the boost modules I was using.
(If you use the deprecated link_directories command you might not notice 
this as often, but I've learned that it's the wrong thing to do and that 
full library paths passed to the linker are the most reliable.)


--
Ryan Pavlik
Human-Computer Interaction Graduate Student
Virtual Reality Applications Center
Iowa State University

rpav...@iastate.edu
http://academic.cleardefinition.com/

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [VS] How to set static run-time for static lib release config?


 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 offer it as one option, in case a user of your 
library is forced to use another library with the static runtime.  It 
doesn't mean that you don't have a static library without it, it just 
means you aren't embedding the entire standard c/c++ runtime library 
into yours, bloating memory usage, and inviting lots of symbol 
collisions when versions don't quite match.  Myself and my colleagues 
have collectively lost significant hair on this one, and it took a while 
for me to figure out exactly what it all meant since it's kind of 
confusing. (and the error messages more so)


For more info:
http://msdn.microsoft.com/en-us/library/abx4dbyh%28VS.80%29.aspx

http://www.rationaldev.com/error_LNK2005_method_already_defined_in_LIBCMT_lib

http://support.microsoft.com/kb/94248 - see section 4 and 5

Ryan

--
Ryan Pavlik
Human-Computer Interaction Graduate Student
Virtual Reality Applications Center
Iowa State University

rpav...@iastate.edu
http://academic.cleardefinition.com/

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] libraryname decoration

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
> versions of libraries, different platforms...

Could you give a concrete example? As, again with Boost, I've never
seen an issue like this.

> What ends up happening in
> projects that rely on those kinds of constructs, is your config system ends
> up having to configure a file specifying the library names for the pragmas
> to work, which ends up being more hassle than just handling linking entirely
> within the build system.  (Plus, then you get the whole "I know exactly what
> my project links against and uses" benefit.)

> I use boost a lot.  I've only used its auto-linking by accident, when it
> guesses the wrong decorated name or wrong location for my platform, at which
> point I realize I missed a library in my build system.  It ends up being a
> slightly more convenient "unresolved symbols" error.

Interesting. What was the cause of this issue?

Olaf
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] libraryname decoration


 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-linking appears to only work on windows with MSVC, and I'm not
prepared to let #pragma comment(lib, "mylib.lib") surrounded by ifdefs sneak
into my source code.)

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 versions of libraries, different platforms... What ends up 
happening in projects that rely on those kinds of constructs, is your 
config system ends up having to configure a file specifying the library 
names for the pragmas to work, which ends up being more hassle than just 
handling linking entirely within the build system.  (Plus, then you get 
the whole "I know exactly what my project links against and uses" benefit.)


I use boost a lot.  I've only used its auto-linking by accident, when it 
guesses the wrong decorated name or wrong location for my platform, at 
which point I realize I missed a library in my build system.  It ends up 
being a slightly more convenient "unresolved symbols" error.


Ryan

--
Ryan Pavlik
Human-Computer Interaction Graduate Student
Virtual Reality Applications Center
Iowa State University

rpav...@iastate.edu
http://academic.cleardefinition.com/

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [VS] How to set static run-time for static lib release config?

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.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] autoheader-like functionality?


 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 result is put into a 
cmake variable. Then after all of that is completed you 
"configure_file(...)" using your .h.in file as input.


#  test.cmake example
# 
#  Now check for needed Header files
# 
INCLUDE (${CMAKE_ROOT}/Modules/CheckIncludeFile.cmake)
macro (CORE_CHECK_INCLUDE_FILE header var prefix)
CHECK_INCLUDE_FILE("${header}"${prefix}_${var} )
endmacro()

CORE_CHECK_INCLUDE_FILE("stddef.h"HAVE_STDDEF_H   MXA)
CORE_CHECK_INCLUDE_FILE("stdint.h"HAVE_STDINT_H   MXA)
CORE_CHECK_INCLUDE_FILE("stdlib.h"HAVE_STDLIB_H   MXA)
CORE_CHECK_INCLUDE_FILE("setjmp.h"HAVE_SETJMP_H   MXA)
CORE_CHECK_INCLUDE_FILE("string.h"HAVE_STRING_H   MXA)
CORE_CHECK_INCLUDE_FILE("stdio.h" HAVE_STDIO_H   MXA)
CORE_CHECK_INCLUDE_FILE("math.h"  HAVE_MATH_H   MXA)
CORE_CHECK_INCLUDE_FILE("time.h"  HAVE_TIME_H   MXA)
CORE_CHECK_INCLUDE_FILE("sys/time.h"  HAVE_SYS_TIME_H   MXA)
CORE_CHECK_INCLUDE_FILE("sys/types.h" HAVE_SYS_TYPES_H   MXA)
CORE_CHECK_INCLUDE_FILE("sys/socket.h"HAVE_SYS_SOCKET_H   MXA)
CORE_CHECK_INCLUDE_FILE("sys/stat.h"  HAVE_SYS_STAT_H   MXA)
CORE_CHECK_INCLUDE_FILE("netinet/in.h"HAVE_NETINET_IN_H   MXA)
CORE_CHECK_INCLUDE_FILE("arpa/inet.h" HAVE_ARPA_INET_H   MXA)
CORE_CHECK_INCLUDE_FILE("unistd.h"HAVE_UNISTD_H   MXA)
CORE_CHECK_INCLUDE_FILE("fcntl.h" HAVE_FCNTL_H   MXA)
CORE_CHECK_INCLUDE_FILE("errno.h" HAVE_ERRNO_H   MXA)

configure_file (Conf.h.in Conf.h @ONLY)
#--- End test.cmake file


// Example Conf.h.in file
/* Define to 1 if you have the  header file. */
#cmakedefine MXA_HAVE_STDDEF_H @MXA_HAVE_STDDEF_H@

/* Define to 1 if you have the  header file. */
#cmakedefine MXA_HAVE_STDINT_H @MXA_HAVE_STDINT_H@

/* Define to 1 if you have the  header file. */
#cmakedefine MXA_HAVE_STDLIB_H @MXA_HAVE_STDLIB_H@

/* Define to 1 if you have the  header file. */
#cmakedefine MXA_HAVE_SETJMP_H @MXA_HAVE_SETJMP_H@

/* Define to 1 if you have the  header file. */
#cmakedefine MXA_HAVE_STRING_H @MXA_HAVE_STRING_H@

/* Define to 1 if you have the  header file.  */
#cmakedefine MXA_HAVE_STDIO_H @MXA_HAVE_STDIO_H@

/* Define to 1 if you have the  header file.  */
#cmakedefine MXA_HAVE_MATH_H @MXA_HAVE_MATH_H@

/* Define to 1 if you have the  header file. */
#cmakedefine MXA_HAVE_TIME_H @MXA_HAVE_TIME_H@

/* Define to 1 if you have the  header file. */
#cmakedefine MXA_HAVE_SYS_TIME_H @MXA_HAVE_SYS_TIME_H@

/* Define to 1 if you have the  header file. */
#cmakedefine MXA_HAVE_SYS_TYPES_H @MXA_HAVE_SYS_TYPES_H@

/* Define to 1 if you have the  header file. */
#cmakedefine MXA_HAVE_SYS_SOCKET_H @MXA_HAVE_SYS_SOCKET_H@

/* Define to 1 if you have the  header file. */
#cmakedefine MXA_HAVE_NETINET_IN_H @MXA_HAVE_NETINET_IN_H@

/* Define to 1 if you have the  header file. */
#cmakedefine MXA_HAVE_ARPA_INET_H @MXA_HAVE_ARPA_INET_H@

/* Define to 1 if you have the  header file. */
#cmakedefine MXA_HAVE_UNISTD_H @MXA_HAVE_UNISTD_H@

/* Define to 1 if you have the  header file. */
#cmakedefine MXA_HAVE_FCNTL_H @MXA_HAVE_FCNTL_H@

/* Define to 1 if you have the  header file. */
#cmakedefine MXA_HAVE_ERRNO_H @MXA_HAVE_ERRNO_H@


at least that is how I do it.
___
Mike Jackson  www.bluequartz.net
Principal Software Engineer   mike.jack...@bluequartz.net
BlueQuartz Software   Dayton, Ohio

On Jul 29, 2010, at 6:25 PM, Clifford Yapp wrote:


I'm now at the point in writing CMake logic where I need to handle the
config.h.in situation, and either have missed the autoheader
equivalent functionality in CMake or it doesn't exist yet.  Can
anybody point me to the "right" approach to this?  I have so-far
found:

The #cmakedefine mechanism and the various CHECK_* functions, which
work fine but aren't autogenerated a.l.a autoheader

A 2009 discussion about autoheader-style functionality:
http://www.cmake.org/pipermail/cmake/2009-March/028293.html
http://www.cmake.org/pipermail/cmake/2009-April/028417.html

and a still-open item in the tracker from 2008:
http://www.cmake.org/Bug/view.php?id=6438&nbn=1

Has there been any recent work on this that I missed?  Our project has
quite a slew of these #defines created by autoheader, most of which
are apparently actually needed, so manually maintaining a list is
gonna be a bit of a tough sell.

Cheers, and any help appreciated,

CY
I think in this case, as in many cases, the initial work will be the 
hard part, figuring out which defines are useful to test and making that

Re: [CMake] Support for multiple components in cpack


 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 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 CPack generators or is there something missing 
even in those generators in your opinion?

An explanation on CPack Component may be found here:
http://www.itk.org/Wiki/CMake:Component_Install_With_CPack

As David said currently the only 2 CPack generators which support Components are
- NSIS
- PackageMaker

I personally would like a wider support including RPM, DEB, TGZ (and
may be ZIP and other archive-like).
There is at least one bug/feature report/request for that for  CPackRPM:
http://public.kitware.com/Bug/view.php?id=7645

 From my point of view for the RPM/DEB/archive (TBZ2  TGZ   TZZIP)
COMPONENT installer there is two "global" options:

A) Put all the components in a single archive with some hierarchical
structure inside
 i.e. build a TGZ   whose structure may be;
   toplevel-name/component1/...
   /component2/...
   etc...

B) Build as many files as components.
  toplevel-name-component1.tgz
  toplevel-name-component2.tgz
  toplevel-name-component3.tgz

The scheme A) is not quite usable for RPM or DEB
but it is ok for "pure" archive like TBZ2 , TGZ, TZ,  ZIP.

My **personal** opinion is that for this kind of installers I'd rather
go for B).
The current problem with B) is that current  CPack architecture does
not authorize it see:
http://public.kitware.com/Bug/view.php?id=10736

Like I said in another mail if we tackle the "multiple file problem" we should
be able to solve the "naming convention problem" too, see:
http://public.kitware.com/Bug/view.php?id=9900

So I would like those 2 bugs (9900, 10736)
solved, which would enable the may-be-easy creation
of full support for CPack COMPONENTs in any case (including bug 7645).

Please comment on those ideas or indicate whether if you agree with my
analysis or not.
Once we have some opinions ideas on this, I'll propose a new/updated
API for CPack generators
concerning this.

I personally would like option B - at the moment I basically work around 
this by making an OPTION and then putting install commands inside if 
statements.  (Basically, not everybody using my work will want every 
part of it, and I can anticipate easily the parts that might not be 
needed - the common case of a runtime system/language that also provides 
a c/c++ api and headers for more advanced usage.)


Ryan

--
Ryan Pavlik
Human-Computer Interaction Graduate Student
Virtual Reality Applications Center
Iowa State University

rpav...@iastate.edu
http://academic.cleardefinition.com/

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] libraryname decoration

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 MSVC, and I'm not
> prepared to let #pragma comment(lib, "mylib.lib") surrounded by ifdefs sneak
> into my source code.)

It's a shame gcc doesn't support it yet. I would love to see support there.

Olaf
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] libraryname decoration

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 module, then there's nothing stopping you from publicizing it and
> encouraging projects (instead of project tools) to use it.  De-facto, not
> de-jure.
>
> (In general, this is my approach to things I'd like CMake to do that it
> doesn't yet, and really, if it doesn't need a core change to be possible,
> it's probably the best place for the code.  Look in any of my projects on
> GitHub, like http://github.com/rpavlik/physical-modeling-utilities , for:
>
> CreateLaunchers.cmake
> CreateDashboardScripts.cmake
> CppcheckTargets.cmake
> DoxygenTargets.cmake
> SetDefaultBuildType.cmake
> EnableExtraCompilerWarnings.cmake
>
> to get an idea of how I solve these things - I solve them once in a module,
> which makes its way into open source code, and hopefully if folks want to do
> similar things they end up finding these modules, and/or even improving
> them...)

Thanks, I'll have a look.

Olaf
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] libraryname decoration

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 conventions.
>>
>> Duplication does not mean that the code is 100% equal.
>
> Let's turn this around for once *evilgrin*: Why?

If the code is 100% equal there's no problem. Problems arise when you
alter one copy but forget to alter other copies. At that point there's
inconsistency.

>> On Windows, at least build type, run-time and platform.
>> But what should and what should not be part of the name doesn't have
>> to be fixed. So that's no problem.
>
> Please do explain. How would this work? What would the API be?

I don't know yet.

> 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!
>
>>
>>> The list goes on and on, and you simply can't expect CMake to make the 
>>> right choice for you (well, it could, but then you would get names that 
>>> easily exceed the maximum length for filenames of almost any operating 
>>> system around and linking against that library without CMake would be utter 
>>> pain).
>>
>> MSVC supports auto linking and Boost shows that using it is even
>> easier then normal linking.
>
> Why? (See how annoying this is? Normally I expect this kind of 
> argumentation/questioning from 4-5 year olds...)

Because I don't have to specify the libs to link against myself.

> To answer partially why I don't think that the boost-way is a solution for 
> every project, just look at how it's implemented.
> http://svn.boost.org/svn/boost/trunk/boost/config/auto_link.hpp
>
> Really cool... THAT's a lot of code that requires a lot of maintenance!

Why?
Yes, it's a lot of code, but why does that imply it requires a lot of
maintenance?

Olaf
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [VS] How to set static run-time for static lib release config?


 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_directories(.)
add_library(
xbt
sql/database.cpp
sql/sql_query.cpp
sql/sql_result.cpp
)
install(TARGETS xbt DESTINATION lib)


Almost nobody uses the static runtime unless someone else's lib forces 
them to, after which they will probably mutter under their breath.  With 
that disclaimer aside:


http://github.com/rpavlik/physical-modeling-utilities/blob/master/cmake/MSVCStaticRuntime.cmake

--
Ryan Pavlik
Human-Computer Interaction Graduate Student
Virtual Reality Applications Center
Iowa State University

rpav...@iastate.edu
http://academic.cleardefinition.com/

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] libraryname decoration

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 mean that the code is 100% equal.

Let's turn this around for once *evilgrin*: Why?

Second: It is impossible for CMake do come up with a good decoration scheme
that covers all possible variations.

Why would this optional scheme have to cover every possible variation?
It's like you're saying that because something can't be done
perfectly, nothing should be done at all.

See, there you say it yourself. CMake has already the scheme of adding a debug
suffix. Not perfect, but it's there and it is working. Stop whining and provide
a patch.

What criteria should enter the decoration? CMake currently chooses only to
offer automatic decoration for debug builds, which is IMHO a valid choice.
Everything else becomes guesswork. Here a list of possible criteria that sprang
to mind, some of which CMake cannot possibly determine:

* build-type (debug, release, release with debug info, etc.)
* 32/64-bit
* compiler suite (e.g. VS{6,7,8,9,10}, Borland, gcc-4.{0..5}, ...)
* SDK (e.g. on Mac) or runtime library on Windows
* single/multi-threaded
* integer size (e.g. for array indices, see Intel MKL)

Isn't this defined by ABI, just like 32/64 bit?

Not necessarily. The MKL offers the choice of using 32 bit integers (maximum
compatibility) and 64 bit integers (huge arrays).

This is a rather dated/historic document, but it describes the various models.
http://www.unix.org/version2/whatsnew/lp64_wp.html

The MKL supports both, ILP64 and LP64, see this:
http://www.intel.com/software/products/mkl/docs/linux/WebHelp/mkl_ug_structure/support_for_ilp64_programming.htm

* license differences (e.g. containing non-free code or DFSG-clean)
* capabilities, such as using ncurses, GNU readline or BSD editline (VERY
different),
using cryptographic software or not (e.g. openssl/gnutls)

On Windows, at least build type, run-time and platform.
But what should and what should not be part of the name doesn't have
to be fixed. So that's no problem.

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!

The list goes on and on, and you simply can't expect CMake to make the right
choice for you (well, it could, but then you would get names that easily exceed
the maximum length for filenames of almost any operating system around and
linking against that library without CMake would be utter pain).

MSVC supports auto linking and Boost shows that using it is even
easier then normal linking.

Why? (See how annoying this is? Normally I expect this kind of
argumentation/questioning from 4-5 year olds...)

To answer partially why I don't think that the boost-way is a solution for
every project, just look at how it's implemented.
http://svn.boost.org/svn/boost/trunk/boost/config/auto_link.hpp

Really cool... THAT's a lot of code that requires a lot of maintenance!

Michael
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 MSVC, and I'm not
prepared to let #pragma comment(lib, "mylib.lib") surrounded by ifdefs
sneak into my source code.)

--
Ryan Pavlik
Human-Computer Interaction Graduate Student
Virtual Reality Applications Center
Iowa State University

rpav...@iastate.edu
http://academic.cleardefinition.com/

___
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] libraryname decoration


 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 impossible for CMake do come up with a good decoration scheme 
that covers all possible variations.

Why would this optional scheme have to cover every possible variation?
It's like you're saying that because something can't be done
perfectly, nothing should be done at all.


What criteria should enter the decoration? CMake currently chooses only to 
offer automatic decoration for debug builds, which is IMHO a valid choice. 
Everything else becomes guesswork. Here a list of possible criteria that sprang 
to mind, some of which CMake cannot possibly determine:

* build-type (debug, release, release with debug info, etc.)
* 32/64-bit
* compiler suite (e.g. VS{6,7,8,9,10}, Borland, gcc-4.{0..5}, ...)
* SDK (e.g. on Mac) or runtime library on Windows
* single/multi-threaded
* integer size (e.g. for array indices, see Intel MKL)

Isn't this defined by ABI, just like 32/64 bit?


* license differences (e.g. containing non-free code or DFSG-clean)
* capabilities, such as using ncurses, GNU readline or BSD editline (VERY 
different),
  using cryptographic software or not (e.g. openssl/gnutls)

On Windows, at least build type, run-time and platform.
But what should and what should not be part of the name doesn't have
to be fixed. So that's no problem.


The list goes on and on, and you simply can't expect CMake to make the right 
choice for you (well, it could, but then you would get names that easily exceed 
the maximum length for filenames of almost any operating system around and 
linking against that library without CMake would be utter pain).

MSVC supports auto linking and Boost shows that using it is even
easier then normal linking.

Olaf


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 module, then there's nothing stopping you 
from publicizing it and encouraging projects (instead of project tools) 
to use it.  De-facto, not de-jure.


(In general, this is my approach to things I'd like CMake to do that it 
doesn't yet, and really, if it doesn't need a core change to be 
possible, it's probably the best place for the code.  Look in any of my 
projects on GitHub, like 
http://github.com/rpavlik/physical-modeling-utilities , for:


   * CreateLaunchers.cmake
   * CreateDashboardScripts.cmake
   * CppcheckTargets.cmake
   * DoxygenTargets.cmake
   * SetDefaultBuildType.cmake
   * EnableExtraCompilerWarnings.cmake

to get an idea of how I solve these things - I solve them once in a 
module, which makes its way into open source code, and hopefully if 
folks want to do similar things they end up finding these modules, 
and/or even improving them...)


--
Ryan Pavlik
Human-Computer Interaction Graduate Student
Virtual Reality Applications Center
Iowa State University

rpav...@iastate.edu
http://academic.cleardefinition.com/

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] libraryname decoration

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.

Let's turn this around for once *evilgrin*: Why?

> 
>> Second: It is impossible for CMake do come up with a good decoration scheme 
>> that covers all possible variations.
> 
> Why would this optional scheme have to cover every possible variation?
> It's like you're saying that because something can't be done
> perfectly, nothing should be done at all.

See, there you say it yourself. CMake has already the scheme of adding a debug 
suffix. Not perfect, but it's there and it is working. Stop whining and provide 
a patch.

> 
>> What criteria should enter the decoration? CMake currently chooses only to 
>> offer automatic decoration for debug builds, which is IMHO a valid choice. 
>> Everything else becomes guesswork. Here a list of possible criteria that 
>> sprang to mind, some of which CMake cannot possibly determine:
>> 
>> * build-type (debug, release, release with debug info, etc.)
>> * 32/64-bit
>> * compiler suite (e.g. VS{6,7,8,9,10}, Borland, gcc-4.{0..5}, ...)
>> * SDK (e.g. on Mac) or runtime library on Windows
>> * single/multi-threaded
>> * integer size (e.g. for array indices, see Intel MKL)
> 
> Isn't this defined by ABI, just like 32/64 bit?

Not necessarily. The MKL offers the choice of using 32 bit integers (maximum 
compatibility) and 64 bit integers (huge arrays).

This is a rather dated/historic document, but it describes the various models.
http://www.unix.org/version2/whatsnew/lp64_wp.html

The MKL supports both, ILP64 and LP64, see this:
http://www.intel.com/software/products/mkl/docs/linux/WebHelp/mkl_ug_structure/support_for_ilp64_programming.htm

> 
>> * license differences (e.g. containing non-free code or DFSG-clean)
>> * capabilities, such as using ncurses, GNU readline or BSD editline (VERY 
>> different),
>>  using cryptographic software or not (e.g. openssl/gnutls)
> 
> On Windows, at least build type, run-time and platform.
> But what should and what should not be part of the name doesn't have
> to be fixed. So that's no problem.

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!

> 
>> The list goes on and on, and you simply can't expect CMake to make the right 
>> choice for you (well, it could, but then you would get names that easily 
>> exceed the maximum length for filenames of almost any operating system 
>> around and linking against that library without CMake would be utter pain).
> 
> MSVC supports auto linking and Boost shows that using it is even
> easier then normal linking.

Why? (See how annoying this is? Normally I expect this kind of 
argumentation/questioning from 4-5 year olds...)

To answer partially why I don't think that the boost-way is a solution for 
every project, just look at how it's implemented.
http://svn.boost.org/svn/boost/trunk/boost/config/auto_link.hpp

Really cool... THAT's a lot of code that requires a lot of maintenance!

Michael
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Support for multiple components in cpack

2010-07-30 Thread Eric Noulard

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 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 CPack generators or is there something missing 
> even in those generators in your opinion?

An explanation on CPack Component may be found here:
   http://www.itk.org/Wiki/CMake:Component_Install_With_CPack

As David said currently the only 2 CPack generators which support Components are
   - NSIS
   - PackageMaker

I personally would like a wider support including RPM, DEB, TGZ (and
may be ZIP and other archive-like).
There is at least one bug/feature report/request for that for  CPackRPM:
http://public.kitware.com/Bug/view.php?id=7645

>From my point of view for the RPM/DEB/archive (TBZ2  TGZ   TZZIP)
COMPONENT installer there is two "global" options:

A) Put all the components in a single archive with some hierarchical
structure inside
i.e. build a TGZ   whose structure may be;
  toplevel-name/component1/...
  /component2/...
  etc...

B) Build as many files as components.
 toplevel-name-component1.tgz
 toplevel-name-component2.tgz
 toplevel-name-component3.tgz

The scheme A) is not quite usable for RPM or DEB
but it is ok for "pure" archive like TBZ2 , TGZ, TZ,  ZIP.

My **personal** opinion is that for this kind of installers I'd rather
go for B).
The current problem with B) is that current  CPack architecture does
not authorize it see:
http://public.kitware.com/Bug/view.php?id=10736

Like I said in another mail if we tackle the "multiple file problem" we should
be able to solve the "naming convention problem" too, see:
http://public.kitware.com/Bug/view.php?id=9900

So I would like those 2 bugs (9900, 10736)
solved, which would enable the may-be-easy creation
of full support for CPack COMPONENTs in any case (including bug 7645).

Please comment on those ideas or indicate whether if you agree with my
analysis or not.
Once we have some opinions ideas on this, I'll propose a new/updated
API for CPack generators
concerning this.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] libraryname decoration

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 decoration scheme 
> that covers all possible variations.

Why would this optional scheme have to cover every possible variation?
It's like you're saying that because something can't be done
perfectly, nothing should be done at all.

> What criteria should enter the decoration? CMake currently chooses only to 
> offer automatic decoration for debug builds, which is IMHO a valid choice. 
> Everything else becomes guesswork. Here a list of possible criteria that 
> sprang to mind, some of which CMake cannot possibly determine:
>
> * build-type (debug, release, release with debug info, etc.)
> * 32/64-bit
> * compiler suite (e.g. VS{6,7,8,9,10}, Borland, gcc-4.{0..5}, ...)
> * SDK (e.g. on Mac) or runtime library on Windows
> * single/multi-threaded
> * integer size (e.g. for array indices, see Intel MKL)

Isn't this defined by ABI, just like 32/64 bit?

> * license differences (e.g. containing non-free code or DFSG-clean)
> * capabilities, such as using ncurses, GNU readline or BSD editline (VERY 
> different),
>  using cryptographic software or not (e.g. openssl/gnutls)

On Windows, at least build type, run-time and platform.
But what should and what should not be part of the name doesn't have
to be fixed. So that's no problem.

> The list goes on and on, and you simply can't expect CMake to make the right 
> choice for you (well, it could, but then you would get names that easily 
> exceed the maximum length for filenames of almost any operating system around 
> and linking against that library without CMake would be utter pain).

MSVC supports auto linking and Boost shows that using it is even
easier then normal linking.

Olaf
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] libraryname decoration

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 this. I don't 
> see code duplication.

If I've got 7 independent libs that use the same decoration rules, how
do I do this without duplicating those rules in every lib?

Olaf
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] [VS] How to set static run-time for static lib release config?

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/database.cpp
sql/sql_query.cpp
sql/sql_result.cpp
)
install(TARGETS xbt DESTINATION lib)
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Bug fix requests for the next release of CMake...

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
CPack generators or is there something missing even in those generators in
your opinion?

Thanks,
David

On Fri, Jul 30, 2010 at 1:02 AM, Kishore wrote:

> I would like to see full support for multiple components in cpack.
>
> On Tuesday 06 Jul 2010 12:01:17 am David Cole wrote:
> > Hi all,
> >
> > Now that we have released CMake 2.8.2 last Monday, and we have switched
> to
> > this new workflow using branches in the git repository, *now* would be a
> > great time to prioritize bug fixes for the next release of CMake.
> >
> > We are leaning towards quarterly releases from now on, scheduling them
> > every 3 months. That would make the next release of CMake version 2.8.3
> > and scheduled to have an "rc1" release candidate in approximately
> > mid-September, 2010.
> >
> > If you have a particular issue that you think should be fixed for
> inclusion
> > in 2.8.3, please bring it up now. Ideally, each issue will be discussed
> as
> > needed on the mailing list to come to any consensus about what should be
> > done to fix it, and then an entry in the bug tracker may be used to keep
> it
> > on the radar screen, and to track activity related to it.
> >
> > Patches are always welcome. Patches that include testing of any new
> > features, or tests that prove a bug is really fixed on the dashboards,
> > basically any patch with testing is preferred over a patch with no
> testing.
> > Also, if you are *adding* code, then you also probably need to add
> *tests*
> > of that code, so that the coverage percentage stays as is or rises.
> >
> > Please discuss issues here as needed, and add notes to existing issues in
> > the bug tracker that you are interested in seeing fixed for 2.8.3 -- we
> > will be looking at the mailing list and activity in the bug tracker to
> > help prioritize the bug fixes that will occur in the next several weeks.
> >
> >
> > Thanks,
> > David Cole
> > Kitware, Inc.
>
> --
> Cheers!
> Kishore
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] libraryname decoration