On Wed, Oct 20, 2010 at 1:15 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
> On Oct 20, 2010, at 04:42 , Sylvain Joyeux wrote:
>
> On 10/20/2010 10:39 AM, Adolfo Rodríguez Tsouroukdissian wrote:
>
> On Mon, Oct 18, 2010 at 4:53 PM, Peter Soetens <peter [..] ...>
> wrote:
>>
>> On Wednesday 13 October 2010 15:27:24 Sylvain Joyeux wrote:
>> > On 10/13/2010 11:06 AM, Peter Soetens wrote:
>> > > On Wednesday 13 October 2010 09:38:11 Willy Lambert wrote:
>> > >> I failed updating my Orocos.
>> > >>
>> > >> I did :
>> > >> autoproj update
>> > >> autoproj build
>> > >> And everything run without errors.
>> > >>
>> > >> But my [autorpoj_path]/rrt/CMakeLists.txt chows a "2.0.2" version.
>> > >
>> > > It does not upgrade you accross major releases. You need to
>> > > re-bootstrap
>> > > with the new bootstrap.sh script in a fresh directory OR run these two
>> > > commands:
>> > >
>> > > autoproj switch-config git
>> > > git://gitorious.com/orocos-toolchain/build.git
>> > > \ branch=toolchain-2.1
>> > > autoproj update
>> >
>> > Yuk. Could we have a 'latest' branch that follows always the latest
>> > version ?
>>
>> Sounds ok to me. So
>> master = stable mainline  (merges new features before a release is made),
>> latest =  latest stable release (tracks latest toolchain-2.x)
>
> IMO a stable release should have stable in its name, probably nothing else.
> Latest sounds closer to trunk than to stable. A similar discussion appeared
> on the ROS list in recent months with respect to the "latest" tag. In the
> end they dropped it because it was creating confusion.
>
> http://code.ros.org/lurker/message/20100802.184003.33b953fd.ca.html
>
> Then I guess we should call the branch "stable" ;-)
>
> +1 on the latest confusion.
> So we have
> toolchain-2.x for tracking v2 releases
> master is the "stable" mainline with most recent features merged
> stable follows the latest toolchain-2.x released?

Ack.

> Does v1 have a place in this list? For those of us stuck with it until 2011

I am only maintaining v1 on SVN branches/trunk. The only thing you got
is rtt-1.0-svn-patches which is a git mirror of the svn trunk. I can rename that
to rtt-1.x-trunk or so...

Peter
--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users

On 12/15/2010 01:27 PM, Willy Lambert wrote:
>
>
> 2010/10/13 Sylvain Joyeux <sylvain [dot] joyeux [..] ...
> <mailto:sylvain [dot] joyeux [..] ...>>
>
> You can also add/override CMake options in autoproj itself -- if you
> don't want to modify the RTT/OCL tree.
>
> Edit autoproj/overrides.rb and add
>
> rtt = Autobuild::Package['rtt']
> rtt.define "VAR", "VALUE"
> rtt.define "VAR", "VALUE"
> rtt.define "VAR", "VALUE"
> rtt.define "VAR", "VALUE"
>
> ocl = Autobuild::Package['ocl']
> ocl.define "VAR", "VALUE"
> ocl.define "VAR", "VALUE"
> ocl.define "VAR", "VALUE"
> ocl.define "VAR", "VALUE"
>
>
>
> I up an old discussion. When I updated my toolchain from 2.0 to 2.1
> things went wrong because some of my cmake options were overrided by
> autoproj update. As 2.2 migrating went wrong I create the toolchain back
> to zero, to be sure having a working installation quickly, so I could
> not test if it went better this time.
>
> The usefull advice to prevent this lost of cmake options was to use
> autoproj/overrides.rb. Can you confirm that this file is not reset when
> switching branches and/or updating the toolchain ?

overrides.rb is governed by the rules of git updates and autoproj
switch-config.

What does this mean in practice ?

* if you bootstrap anew, it *is* lost, obviously
* if you do switch-config and simply change the branch, it will be
considered by git as a local change. I.e. if the new branch has
modifications in overrides.rb, then autoproj will refuse updating
(you will have to merge yourself)

If you guys have a better way to store 'local' options, I'm listening.

interesting

which is the recommanded use

2010/10/13 S Roderick <kiwi [dot] net [..] ...>

> On Oct 13, 2010, at 12:58 , Sylvain Joyeux wrote:
>
> > You can also add/override CMake options in autoproj itself -- if you
> > don't want to modify the RTT/OCL tree.
> >
> > Edit autoproj/overrides.rb and add
> >
> > rtt = Autobuild::Package['rtt']
> > rtt.define "VAR", "VALUE"
> > rtt.define "VAR", "VALUE"
> > rtt.define "VAR", "VALUE"
> > rtt.define "VAR", "VALUE"
> >
> > ocl = Autobuild::Package['ocl']
> > ocl.define "VAR", "VALUE"
> > ocl.define "VAR", "VALUE"
> > ocl.define "VAR", "VALUE"
> > ocl.define "VAR", "VALUE"
>
> Very useful to know. Is that doc'd on the toolchain website/wiki?
> S
>

On Oct 13, 2010, at 12:32 , Willy Lambert wrote:

>
>
> 2010/10/13 S Roderick <kiwi [dot] net [..] ...>
> On Oct 13, 2010, at 12:02 , Willy Lambert wrote:
>
>>
>>
>> 2010/10/13 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>> On 10/13/2010 11:06 AM, Peter Soetens wrote:
>> On Wednesday 13 October 2010 09:38:11 Willy Lambert wrote:
>> I failed updating my Orocos.
>>
>> I did :
>> autoproj update
>> autoproj build
>> And everything run without errors.
>>
>> But my [autorpoj_path]/rrt/CMakeLists.txt chows a "2.0.2" version.
>>
>> It does not upgrade you accross major releases. You need to re-bootstrap with
>> the new bootstrap.sh script in a fresh directory OR run these two commands:
>>
>> autoproj switch-config git git://gitorious.com/orocos-toolchain/build.git \
>> branch=toolchain-2.1
>> autoproj update
>>
>> Yuk. Could we have a 'latest' branch that follows always the latest version ?
>>
>>
>> by the way, do the autoproj update erase my CMakeCache files ?
>> Yes, it does. The problem is that CMake has a tendency to cache way too much information and that is the best way to ensure smooth long time upgrades.
>>
>> What kind of issue did that cause for you ?
>>
>> nothing hurtfull, but i activated logging in ocl and changed rtt option in order to use "real time logging" (as mentionned in the wiki); so the only impact is that it broke my hudson builds ;)
>>
>> maybe i should mention this variables in my cmake scripts, but as my orocos integration in cmake is not perfect currently i used to modify cmake cache
>
> Create rtt/orocos-rtt.cmake and ocl/orocos-ocl.cmake files in the source tree, and set your defaults there. Then just cmake'ing again will keep your options.
>
> thanks for this advice i will apply this on my toolchain
>
>
> Mine contain items like this for RTT
>
>

> ...
> OPTION( OS_RT_MALLOC "" ON)
> OPTION( OS_RT_MALLOC_SBRK "" OFF)
> OPTION( OS_RT_MALLOC_MMAP "" OFF)
> OPTION( OS_RT_MALLOC_STATS "" ON)
> OPTION( OS_RT_MALLOC_DEBUG "" ON)
> 
> OPTION(OROSEM_LOG4CPP_LOGGING "" ON 
> ...
> 

> ...
> OPTION(BUILD_RTALLOC "" ON)
> OPTION(BUILD_LOGGING "" ON)
> 
> OPTION(BUILD_TESTS "" OFF)
> OPTION(BUILD_HELLOWORLD "" OFF)
> ...
>