On 04/26/2011 08:52 PM, Rosen Diankov wrote:
> i'm not comfortable with managing all the dynamic libraries and putting
> them into LINK_INTERFACE_LIBRARIES.
> OpenRAVE contains a lot of 3rdparty libraries stored in source in case
> users don't have the system install versions
The distinction for L
about import targets and the static library export problem:
it would be great if there was an option for exporting that will set
static libraries to be ignored. i'm not comfortable with managing all
the dynamic libraries and putting them into LINK_INTERFACE_LIBRARIES.
OpenRAVE contains a lot of 3r
On 04/15/2011 09:48 AM, Rosen Diankov wrote:
> From what i understood in the documentation, I would have to set
> LINK_INTERFACE_LIBRARIES to all the non-static install libraries
> right?
Yes. It should list the libraries that applications should link when
linking to your library. If your public
After thinking about it, it really doesn't make sense for static
libraries to be part of the exports.
rosen,
2011/4/15 Rosen Diankov :
>> set_property(TARGET mysharedlib PROPERTY LINK_INTERFACE_LIBRARIES "")
>
> but wouldn't that also affect how the libraries are linked? for
> example, libopenrav
> set_property(TARGET mysharedlib PROPERTY LINK_INTERFACE_LIBRARIES "")
but wouldn't that also affect how the libraries are linked? for
example, libopenrave target links to boost. and any module using
libopenrave should still use boost. however the static libraries
libopenrave links to like crlib
On 04/15/2011 08:49 AM, Rosen Diankov wrote:
> thanks for the answers! for now i'm not sure if i want to spend time
> tweaking the LINK_INTERFACE_LIBRARIES property, it's getting a little
> too complicated just to get exports working right.
It's probably just one line right after add_library(mysha
Hi Brad,
thanks for the answers! for now i'm not sure if i want to spend time
tweaking the LINK_INTERFACE_LIBRARIES property, it's getting a little
too complicated just to get exports working right.
i was reading this:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/readme.txt
which says X
On 04/15/2011 06:06 AM, Rosen Diankov wrote:
> I wasn't really sure what changes are needed to use the new registry
> functions you committed.
No changes are needed to your config file or find module. The command
will look at the system package registry automatically. It is up to
your installer
Although the logical package name is OpenRAVE, i decided it would be
more consistent with the rest of the installation files if
openrave-config.cmake was used.
rosen,
2011/4/15 Rosen Diankov :
> Hi Brad,
>
> Ok, just released a new version of OpenRAVE that uses configuration
> files. I'm attachin
Hi Brad,
Ok, just released a new version of OpenRAVE that uses configuration
files. I'm attaching the final cmake files, can you double check to
make sure there are no problems?
I wasn't really sure what changes are needed to use the new registry
functions you committed. is there a nightly build
On 04/13/2011 11:32 AM, Rosen Diankov wrote:
> ok, the changes you are proposing sound exciting! perhaps this can be
> a start for a truly cross platform package management system ;0)
If only ;)
> so is the best approach for now to create a minimal FindOpenRAVE.cmake
> to give to user, and put Fi
hi brad,
ok, the changes you are proposing sound exciting! perhaps this can be
a start for a truly cross platform package management system ;0)
so is the best approach for now to create a minimal FindOpenRAVE.cmake
to give to user, and put FindOpenRAVEConfig.cmake in
$installprefix/lib/cmake/?
On 04/12/2011 08:02 PM, Rosen Diankov wrote:
> Perhaps I missed something, but FindX.cmake packages will look for
> that, while the configuration method you are suggesting will not.
Correct. I've been meaning to address this for a long time.
> It would be great if find_package also searches the
Hi Brad,
Ok, the design decisions leading up to package configuration files are
making sense now.
I was trying to write a configuration file in the same way a
FindX.cmake file, which lead to the confusion.
There is still one thing that doesn't make sense. OpenRAVE windows
installations write to
On 04/11/2011 07:25 PM, Rosen Diankov wrote:
> I have one question about case though. If it is OpenRAVE, then do all
> the variables have to be prefixed with the correct case OpenRAVE? In
> that case, would it be easier to do openrave-config.cmake and then
> have openrave_XXX variables set? what is
hi brad,
one more question. Even if a openrave-config.cmake file is present, we
should also have a Findopenrave.cmake file right?
After playing around with openrave-config.cmake, it turns out that
openrave_FOUND gets set to TRUE no matter how hard
openrave-config.cmake tries to set it to FALSE. (
hi brad,
Thanks for the advise, the license will not be issue and the
OpenRAVEConfig.cmake idea is excellent!
I have one question about case though. If it is OpenRAVE, then do all
the variables have to be prefixed with the correct case OpenRAVE? In
that case, would it be easier to do openrave-con
On 04/11/2011 02:20 AM, Rosen Diankov wrote:
> My name is Rosen Diankov and am the main developer for a robotics
> motion planning environment named OpenRAVE.
Great, thanks for coming to us with this contribution.
> Because we'll be always updating the URL, do you think we can setup
> some automa
Dear CMake Developers,
My name is Rosen Diankov and am the main developer for a robotics
motion planning environment named OpenRAVE.
http://openrave.programmingvision.com
OpenRAVE is all managed with cmake and compiles on any *nix, windows,
and mac osx. Most of the users (about 200 at the moment
19 matches
Mail list logo
