Hi J-S,
The lines in OsgMacroUtils.cmake must have some reason for their
existence. I don't know whether its was introduced by Luigi Calori or
Eric Wing or another Windows developer during the development of the
OSG's CMake build system. I have to defer to Windows experts on the
CMake build
Hi Paul,
I don't know why the file tries to specify a different extension for IDE vs
non-IDE, nor do I know how this worked using CMake 2.4.x. Should we just
submit this as a fix and see who screams?
That's what I think we should do too. Asking on the list about why this
was needed didn't
Hi Thomas,
Good to know someone is taking this on, thanks! This CMake warning can be
fixed as described in the message - and the default (CMP0003 OLD) seems to
be working ok.
But that isn't a fix, it's a workaround... Someday, CMake will remove
the old behaviour (that's what deprecated
Hi J-S,
On Fri, May 9, 2008 at 1:59 PM, Jean-Sébastien Guay
[EMAIL PROTECTED] wrote:
That's what I think we should do too. Asking on the list about why this was
needed didn't elicit any response, so changing it might. grin
Breaking a build for one user to fix a build another isn't really
Hi Robert,
The lines in OsgMacroUtils.cmake must have some reason for their
existence.
Of course, but I cannot figure out what that reason is.
1. They cause a problem with CMake 2.6 which is now officially released...
2. Removing them (the fix for CMake 2.6) doesn't seem to cause a problem
Jean-Sébastien Guay wrote:
Hi Robert,
The lines in OsgMacroUtils.cmake must have some reason for their
existence.
Of course, but I cannot figure out what that reason is.
1. They cause a problem with CMake 2.6 which is now officially released...
2. Removing them (the fix for CMake 2.6)
Hello Robert,
With the aim of tracking down the introduction of this workaround I've
gone through the svn logs for OsgMacroUtils.cmake and it looks like
the revision of importance is 7865 - this just so happens to be the
latest update to OsgmacroUtils so is a pretty recent change:
Hmm,
Hi Bill,
I am not quite sure what is
going on, so perhaps someone can explain it to me...
F(NOT MSVC_IDE)
TARGET_LINK_LIBRARIES(${TRGTNAME}
optimized ${OUTPUT_LIBDIR}/${LINKLIB}.lib
debug ${OUTPUT_LIBDIR}/${LINKLIB}${CMAKE_DEBUG_POSTFIX}.lib)
ELSE(NOT MSVC_IDE)
Jean-Sébastien Guay wrote:
Hello Robert,
Of course, I'd like to know if it will break something else. But
honestly, I think we cover pretty much 100% of the possible cases on
Windows with MSVC here... And no one has stepped up to say it will break
it for them.
J-S
You should not have
Hoffman
Sent: Friday, May 09, 2008 7:23 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] OSG 2.4, CMake 2.6 and Visual C++
2008: Missing .lib extension for internal dependencies causes
linker error
Jean-Sébastien Guay wrote:
Hi Robert,
The lines in OsgMacroUtils.cmake must have
Hi, I' ve been mostly offline for the last 3days, I did not personally
test 2.6 yet (I' m willing to do soon) but do not think putting a .lib
extension would harm windows builds.
I personally do not remember having set up this ide special case, but
probably 2.4 was more tolerant than 2.6 on
Luigi Calori wrote:
Hi, I' ve been mostly offline for the last 3days, I did not personally
test 2.6 yet (I' m willing to do soon) but do not think putting a .lib
extension would harm windows builds.
I personally do not remember having set up this ide special case, but
probably 2.4 was more
Hi Bill,
You should not have to add .lib, CMake should do that for you. If these
are libraries that CMake is building as part of the OSG build, then you
should only be linking to the target name, and not messing around with
low level .lib type of stuff.
That's what we were doing, and it
Jean-Sébastien Guay wrote:
Hi Bill,
You should not have to add .lib, CMake should do that for you. If
these are libraries that CMake is building as part of the OSG build,
then you should only be linking to the target name, and not messing
around with low level .lib type of stuff.
That's
.
In the simple case, I just tested with 2.4.8 and 2.6.0 this works fine:
add_executable(bar foo.c)
target_link_libraries(bar foo)
foo.lib is linked for both vs IDE and makefiles.
Let's go back to the macro LINK_INTERNAL. I think the issue was
trying to get around a bug in 2.4.7.
So, I think you don't need the macro at all for 2.4.8 and greater.
Are all the input libraries to LINK_INTERNAL things that CMake is building?
Should be (in this case). I'll try to see what I can find out, but I
really did see the case where generating with 2.6 would not get the .lib
appended
Bill Hoffman wrote:
Jean-Sébastien Guay wrote:
Hi Bill,
You should not have to add .lib, CMake should do that for you. If
these are libraries that CMake is building as part of the OSG build,
then you should only be linking to the target name, and not messing
around with low level .lib type
Thanks for your help, Bill.
So, I think you don't need the macro at all for 2.4.8 and greater.
It should just be:
target_link_libraries(osgDB osg OpenThreads)
Will this correctly append the d suffix for debug builds? That is,
osg.lib for release, and osgd.lib for debug. Appending d to the
Paul Martz wrote:
Thanks for your help, Bill.
So, I think you don't need the macro at all for 2.4.8 and greater.
It should just be:
target_link_libraries(osgDB osg OpenThreads)
Will this correctly append the d suffix for debug builds? That is,
osg.lib for release, and osgd.lib for debug.
Jean-Sébastien Guay wrote:
Hi Bill,
Will this correctly append the d suffix for debug builds? That is,
osg.lib for release, and osgd.lib for debug. Appending d to the
base
library file name is one of the tasks that this macro performs, so if
we're
going to get rid of the macro, I want to
Hi Bill,
Additionally, as Luigi said, the macro puts lib files in
CMAKE_INSTALL_PREFIX/lib, and DLL files in CMAKE_INSTALL_PREFIX/bin,
I just realized (as I should have before) that this is what causes the
issues we have... CMAKE_INSTALL_PREFIX being an absolute path most of
the time,
Hi Bill,
So, why are you trying to build directly into the install prefix? Why
not let the install command do that work? If you really want to do
that, then you should look at RUNTIME_OUTPUT_DIRECTORY,
ARCHIVE_OUTPUT_DIRECTORY, and LIBRARY_OUTPUT_DIRECTORY target properties.
We're not
So, why are you trying to build directly into the install
prefix? Why
not let the install command do that work? If you really want to do
that, then you should look at RUNTIME_OUTPUT_DIRECTORY,
ARCHIVE_OUTPUT_DIRECTORY, and LIBRARY_OUTPUT_DIRECTORY target
properties.
One thing to
Paul Martz wrote:
So, why are you trying to build directly into the install
prefix? Why
not let the install command do that work? If you really want to do
that, then you should look at RUNTIME_OUTPUT_DIRECTORY,
ARCHIVE_OUTPUT_DIRECTORY, and LIBRARY_OUTPUT_DIRECTORY target
properties.
Hi Thomas,
I'm not a Windows users so can't provide direct answers on this topic,
but hopefully can point you in the a useful direction. My best guess
is that the latest version of CMake has is not quite backwards
compatible with the CMake scripts we use that developed against CMake
2.4.x.
Hi Thomas,
If you replace ln. 33 in CMakeModules/OsgMacroUtils.cmake
TARGET_LINK_LIBRARIES(${TRGTNAME} optimized ${OUTPUT_LIBDIR}/${LINKLIB} debug
${OUTPUT_LIBDIR}/${LINKLIB}${CMAKE_DEBUG_POSTFIX})
with something like in ln. 31
TARGET_LINK_LIBRARIES(${TRGTNAME} optimized
Hello Thomas,
Could anyone let me know if this is likely a misconfiguration of mine or if
this really is a bug that should be addressed/fixed in the next release of
the OSG library?
I reported this about a week before the 2.4.0 stable release, but CMake
2.6 was not officially released yet,
]
Subject: Re: [osg-users] OSG 2.4, CMake 2.6 and Visual C++ 2008:
Missing .lib extension for internal dependencies causes linker error
To: osg-users@lists.openscenegraph.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Hi Thomas,
If you replace
Hi Thomas,
On Thu, May 8, 2008 at 3:33 PM, Thomas Tränkler
[EMAIL PROTECTED] wrote:
Thanks for the quick fix, so I guess we should file the CMake issue a bug
and communicate it to the OSG developers - How is that done here?
osg-users is where we all hang out. There aren't really OSG
Hi Robert, Thomas,
As to whether its a CMake bug or an OSG build system compatibility
problem w.r.t CMake 2.6 I don't know yet, once things shake down a bit
more we'll know more.
Have you taken a look at the lines in question in
CMakeModules/OsgMacroUtils.cmake? I honestly can't figure out
?
-Paul
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Marcin Prus
Sent: Thursday, May 08, 2008 4:38 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] OSG 2.4, CMake 2.6 and Visual C++
2008: Missing .lib extension
without deleting the rest
and changing the subject manually?
Thanks,
Thomas
--
Date: Thu, 08 May 2008 09:16:09 -0400
From: Jean-S?bastien Guay [EMAIL PROTECTED]
Subject: Re: [osg-users] OSG 2.4, CMake 2.6 and Visual C++ 2008:
Missing .lib extension for internal
32 matches
Mail list logo
