Hi all,
I would like to put packages in subdirectories and can't find the right way of configuring this. Background is that I want to set up a product line on base of Orocos (no ROS) and want to separate the packages of the line core from packages of the products. Also we will get some supporting tools which should not mess up the line structure.
I tried to extend the INSTALL_PATH in the make file, but that did not work out.
What I think about is something like:
/opt/orocos/install
/opt/orocos/install/LineCore
/opt/orocos/install/Product_1
/opt/orocos/install/Product_2
/opt/orocos/install/Tools
/opt/orocos/install/Tools/Tool_1
/opt/orocos/install/Tools/Tool_2
And so on . .. .
Is this possible at all?? And if yes what's the easiest way to achieve this?? (I use cmake)
Ciao Joerg
packages in subdirectorys???
On Friday 10 June 2011 13:19:19 joerg [..] ... wrote:
> Hi all,
>
> I would like to put packages in subdirectories and can't find the right way
> of configuring this. Background is that I want to set up a product line on
> base of Orocos (no ROS) and want to separate the packages of the line core
> from packages of the products. Also we will get some supporting tools
> which should not mess up the line structure.
>
> I tried to extend the INSTALL_PATH in the make file, but that did not work
> out.
INSTALL_PATH is broken :-( We're fixing this in another thread.
Use -DCMAKE_PREFIX_PATH=/opt/orocos/install/Tools/Tool_1 etc when running
cmake in your build directory.
>
> What I think about is something like:
>
> /opt/orocos/install
>
> /opt/orocos/install/LineCore
>
> /opt/orocos/install/Product_1
>
> /opt/orocos/install/Product_2
>
> /opt/orocos/install/Tools
>
> /opt/orocos/install/Tools/Tool_1
>
> /opt/orocos/install/Tools/Tool_2
>
> And so on . .. .
>
> Is this possible at all?? And if yes what's the easiest way to achieve
> this?? (I use cmake)
There are two things to consider here:
1. Orocos deployment assumes that the build products of packages are installed
as subdirs of the 'lib/orocos' and 'include/orocos' directories.
2. It is possible to use different prefixes for each product, but then you'll
have to extend your RTT_COMPONENT_PATH for each prefix.
So in order for this to work, you'll arrive at something like:
/opt/orocos/install/Tools/Tool_1/lib/orocos/Tool_1/lib*.so
/opt/orocos/install/Tools/Tool_1/include/orocos/Tool_1/*.hpp
And the RTT_COMPONENT_PATH must include
/opt/orocos/install/Tools/Tool_1/lib/orocos/
And your deployment will import("Tool_1")
>
> Ciao
> Joerg
Peter
packages in subdirectorys???
On Jun 11, 2011, at 06:18 , joerg [..] ... wrote:
>
>> Hi all,
>>
>> I would like to put packages in subdirectories and can't find the right way
>> of configuring this. Background is that I want to set up a product line on
>> base of Orocos (no ROS) and want to separate the packages of the line core
>> from packages of the products. Also we will get some supporting tools
>> which should not mess up the line structure.
>>
>> I tried to extend the INSTALL_PATH in the make file, but that did not work
>> out.
>
> INSTALL_PATH is broken :-( We're fixing this in another thread.
> Use -DCMAKE_PREFIX_PATH=/opt/orocos/install/Tools/Tool_1 etc when running
> cmake in your build directory.
>
>>
>> What I think about is something like:
>>
>> /opt/orocos/install
>>
>> /opt/orocos/install/LineCore
>>
>> /opt/orocos/install/Product_1
>>
>> /opt/orocos/install/Product_2
>>
>> /opt/orocos/install/Tools
>>
>> /opt/orocos/install/Tools/Tool_1
>>
>> /opt/orocos/install/Tools/Tool_2
>>
>> And so on . .. .
>>
>> Is this possible at all?? And if yes what's the easiest way to achieve
>> this?? (I use cmake)
>
> There are two things to consider here:
>
> 1. Orocos deployment assumes that the build products of packages are installed
> as subdirs of the 'lib/orocos' and 'include/orocos' directories.
>
> 2. It is possible to use different prefixes for each product, but then you'll
> have to extend your RTT_COMPONENT_PATH for each prefix.
>
> So in order for this to work, you'll arrive at something like:
>
> /opt/orocos/install/Tools/Tool_1/lib/orocos/Tool_1/lib*.so
> /opt/orocos/install/Tools/Tool_1/include/orocos/Tool_1/*.hpp
>
> And the RTT_COMPONENT_PATH must include
> /opt/orocos/install/Tools/Tool_1/lib/orocos/
>
> And your deployment will import("Tool_1")
>
>>
>> Ciao
>> Joerg
>
> Peter
>
>
> THANKS Peter...
>
> I gona try this out, the additional paths are not nice but better than having all the stuff in one directory ...
>
> Ciao
> Joerg
>
> Computer are like air conditioner, they stop working properly when opening windows
>
> Nop, does not work that easy . .
>
> I set the CMAKE_PREFIX_PATH in the Makefile to:
>
> all:
> mkdir -p build
> cd build ; cmake .. -DCMAKE_PREFIX_PATH=/opt/orocos/install/MachineControl && make
I think that they might have meant CMAKE_INSTALL_PREFIX instead of CMAKE_PREFIX_PATH? Try that ...
S
packages in subdirectorys???
On Jun 18, 2011, at 11:21 , joerg [..] ... wrote:
>
>> On Jun 11, 2011, at 06:18 , joerg [..] ... wrote:
>>>
> joerg [..] ... wrote:
>>>> Hi all,
>>>>
>>>> I would like to put packages in subdirectories and can't find the right
>>>> way of configuring this. Background is that I want to set up a product
>>>> line on base of Orocos (no ROS) and want to separate the packages of
>>>> the line core from packages of the products. Also we will get some
>>>> supporting tools which should not mess up the line structure.
>>>>
>>>> I tried to extend the INSTALL_PATH in the make file, but that did not
>>>> work out.
>>>
>>> INSTALL_PATH is broken :-( We're fixing this in another thread.
>>> Use -DCMAKE_PREFIX_PATH=/opt/orocos/install/Tools/Tool_1 etc when running
>>> cmake in your build directory.
>>>
>>>> What I think about is something like:
>>>>
>>>> /opt/orocos/install
>>>>
>>>> /opt/orocos/install/LineCore
>>>>
>>>> /opt/orocos/install/Product_1
>>>>
>>>> /opt/orocos/install/Product_2
>>>>
>>>> /opt/orocos/install/Tools
>>>>
>>>> /opt/orocos/install/Tools/Tool_1
>>>>
>>>> /opt/orocos/install/Tools/Tool_2
>>>>
>>>> And so on . .. .
>>>>
>>>> Is this possible at all?? And if yes what's the easiest way to achieve
>>>> this?? (I use cmake)
>>>
>>> There are two things to consider here:
>>>
>>> 1. Orocos deployment assumes that the build products of packages are
>>> installed as subdirs of the 'lib/orocos' and 'include/orocos'
>>> directories.
>>>
>>> 2. It is possible to use different prefixes for each product, but then
>>> you'll have to extend your RTT_COMPONENT_PATH for each prefix.
>>>
>>> So in order for this to work, you'll arrive at something like:
>>>
>>> /opt/orocos/install/Tools/Tool_1/lib/orocos/Tool_1/lib*.so
>>> /opt/orocos/install/Tools/Tool_1/include/orocos/Tool_1/*.hpp
>>>
>>> And the RTT_COMPONENT_PATH must include
>>> /opt/orocos/install/Tools/Tool_1/lib/orocos/
>>>
>>> And your deployment will import("Tool_1")
>>>
>>>> Ciao
>>>> Joerg
>>>
>>> Peter
>>>
>>>
>>> THANKS Peter...
>>>
>>> I gona try this out, the additional paths are not nice but better than
>>> having all the stuff in one directory ...
>>>
>>> Ciao
>>> Joerg
>>>
>>> Computer are like air conditioner, they stop working properly when
>>> opening windows
>>>
>>> Nop, does not work that easy . .
>>>
>>> I set the CMAKE_PREFIX_PATH in the Makefile to:
>>> all:
>>> mkdir -p build
>>> cd build ; cmake ..
>>> -DCMAKE_PREFIX_PATH=/opt/orocos/install/MachineControl && make
>>
>> I think that they might have meant CMAKE_INSTALL_PREFIX instead of
>> CMAKE_PREFIX_PATH? Try that ... S
>
> Stephen is right, I made a typo. It's -DCMAKE_INSTALL_PREFIX=/opt/... you need
> to use. You can check that it's used by looking for that variable in the
> build/CMakeCache.txt file.
>
> Peter
>
>
> Hi Peter,
>
> I tried this, but as I wrote already its completely ignored !?!?
> When I set "-DCMAKE_INSTALL_PREFIX=/opt/orocos/install/MachineControl" instead of
> "-DINSTALL_PATH=orocos" a call of "make install" tries to install in "/usr/local/lib/orocos"
>
> !??!?!?!
>
> I checked out the toolchain-2.4 freshly today, in case there was a fix for this, but now other problems appeared (see new thread about orocreate-pkg)
What was your exact cmake line? Some items need to go _before_ the source path ... if you didn't do it this way, maybe try
cd /path/to/build
rm -rf *
cmake -DCMAKE_INSTALL_PREFIX=/path/to/install /path/to/source
packages in subdirectorys???
On Sat, Jun 18, 2011 at 5:58 PM, <joerg [..] ...> wrote:
>
>
>>
>>> On Jun 11, 2011, at 06:18 , joerg [..] ... wrote:
>>>>
>> joerg [..] ... wrote:
>>>>> Hi all,
>>>>>
>>>>> I would like to put packages in subdirectories and can't find the right
>>>>> way of configuring this. Background is that I want to set up a product
>>>>> line on base of Orocos (no ROS) and want to separate the packages of
>>>>> the line core from packages of the products. Also we will get some
>>>>> supporting tools which should not mess up the line structure.
>>>>>
>>>>> I tried to extend the INSTALL_PATH in the make file, but that did not
>>>>> work out.
>>>>
>>>> INSTALL_PATH is broken :-( We're fixing this in another thread.
>>>> Use -DCMAKE_PREFIX_PATH=/opt/orocos/install/Tools/Tool_1 etc when running
>>>> cmake in your build directory.
>>>>
>>>>> What I think about is something like:
>>>>>
>>>>> /opt/orocos/install
>>>>>
>>>>> /opt/orocos/install/LineCore
>>>>>
>>>>> /opt/orocos/install/Product_1
>>>>>
>>>>> /opt/orocos/install/Product_2
>>>>>
>>>>> /opt/orocos/install/Tools
>>>>>
>>>>> /opt/orocos/install/Tools/Tool_1
>>>>>
>>>>> /opt/orocos/install/Tools/Tool_2
>>>>>
>>>>> And so on . .. .
>>>>>
>>>>> Is this possible at all?? And if yes what's the easiest way to achieve
>>>>> this?? (I use cmake)
>>>>
>>>> There are two things to consider here:
>>>>
>>>> 1. Orocos deployment assumes that the build products of packages are
>>>> installed as subdirs of the 'lib/orocos' and 'include/orocos'
>>>> directories.
>>>>
>>>> 2. It is possible to use different prefixes for each product, but then
>>>> you'll have to extend your RTT_COMPONENT_PATH for each prefix.
>>>>
>>>> So in order for this to work, you'll arrive at something like:
>>>>
>>>> /opt/orocos/install/Tools/Tool_1/lib/orocos/Tool_1/lib*.so
>>>> /opt/orocos/install/Tools/Tool_1/include/orocos/Tool_1/*.hpp
>>>>
>>>> And the RTT_COMPONENT_PATH must include
>>>> /opt/orocos/install/Tools/Tool_1/lib/orocos/
>>>>
>>>> And your deployment will import("Tool_1")
>>>>
>>>>> Ciao
>>>>> Joerg
>>>>
>>>> Peter
>>>>
>>>>
>>>> THANKS Peter...
>>>>
>>>> I gona try this out, the additional paths are not nice but better than
>>>> having all the stuff in one directory ...
>>>>
>>>> Ciao
>>>> Joerg
>>>>
>>>> Computer are like air conditioner, they stop working properly when
>>>> opening windows
>>>>
>>>> Nop, does not work that easy . .
>>>>
>>>> I set the CMAKE_PREFIX_PATH in the Makefile to:
>>>> all:
>>>> mkdir -p build
>>>> cd build ; cmake ..
>>>> -DCMAKE_PREFIX_PATH=/opt/orocos/install/MachineControl && make
>>>
>>> I think that they might have meant CMAKE_INSTALL_PREFIX instead of
>>> CMAKE_PREFIX_PATH? Try that ... S
>>
>> Stephen is right, I made a typo. It's -DCMAKE_INSTALL_PREFIX=/opt/... you need
>> to use. You can check that it's used by looking for that variable in the
>> build/CMakeCache.txt file.
>>
>> Peter
>>
>>
>> Hi Peter,
>>
>> I tried this, but as I wrote already its completely ignored !?!?
>> When I set "-DCMAKE_INSTALL_PREFIX=/opt/orocos/install/MachineControl" instead of
>> "-DINSTALL_PATH=orocos" a call of "make install" tries to install in "/usr/local/lib/orocos"
>>
>> !??!?!?!
>>
>> I checked out the toolchain-2.4 freshly today, in case there was a fix for this, but now other problems appeared (see new thread about orocreate-pkg)
>
> What was your exact cmake line? Some items need to go _before_ the source path ... if you didn't do it this way, maybe try
>
> cd /path/to/build
> rm -rf *
> cmake -DCMAKE_INSTALL_PREFIX=/path/to/install /path/to/source
>
>
> Jop, that worked ...
>
> Only eventually I will get quite a lot of packages and installing them all by hand is not a good thing. Especially as I have to do the stuff for Linux and for Windows(grrrrr... )
>
> I need to find some automatism to do this
>
Ok, so that was your problem... I'd like to have more input why you
want to install all packages in different 'prefix' directories,
instead of using a common prefix and then installing in a different
subdir (named as the package) for each package. The latter is the
default and actually covers your case. The files are not mixed, they
only share a common ancestor /opt/orocos/lib/orocos or
/opt/orocos/include/orocos. The only exception to this rule I see are
the 'support' libraries which are installed together in
/opt/orocos/lib .
Peter
--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
Re: packages in subdirectorys???
> I need to find some automatism to do this >
Ok, so that was your problem... I'd like to have more input why you want to install all packages in different 'prefix' directories, instead of using a common prefix and then installing in a different subdir (named as the package) for each package. The latter is the default and actually covers your case. The files are not mixed, they only share a common ancestor /opt/orocos/lib/orocos or /opt/orocos/include/orocos. The only exception to this rule I see are the 'support' libraries which are installed together in /opt/orocos/lib .
Peter -- Orocos-Users mailing list Orocos-Users [..] ... http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
Hi Peter,
as I said I want to set up a product line consisting of the line core, the individual products and some supporting tools.
What I want to achieve is that all packages of the line core are sitting below one sub-dir, all packages unique for an individual product in a sub-dir for this product and supporting tools should get there own sub-dirs too. I want to have a separate package for every component, means I will end up with quite a lot of packages...
I'm currently migrating individual products into the line structure and for the sake of time I have to reuse a lot of old code, from which I know that it will be replaced later on. For this later changes I want the ability to care about single components only thats why I want to have them in single packages. A nice side effect is that it gets (psychologically) harder to pointer wild around, means the chance is higher that we stick to clear interfaces ;-)
Also when the first product based on the line core is release, I don't want to minimize the changes on interfaces of the line core. Having them in a separate (don't change without asking) folder is again a nice (psychologically) barrier.
If such a usage is not foreseen or hard to achieve than I have to find another way of separation e.g. on the code level. Only it would be nice ...
Ciao Joerg
Computer are like air conditioner, they stop working properly when opening windows