Dear Peter and the other Orocos Devs,
As part of my crusade to make our flight code easier to install, I
have extended the deployer wrapper script so that it searches up the
directory hierarchy for a file with a special name (currently
.rtt_componont_path), and adds any lines in it to RTT_COMPONENT_PATH.
This file can then be added to the root of a git repository.
This makes it far easier to ship code that does NOT require the user
to set up any environment variables, as long as they run the deployer
from anywhere in the shipped code (git repository). It also makes it
easier to switch between multiple clones of repositories containing
components (i.e. the deployer will use the components corresponding to
the repo you have cd'd into).
Please let me know if any changes are necessary to get this change
mainlined. I would prefer not to have to maintain a separate branch
of ocl for something so trivial, and others might find it useful
(although something will have to be added to the docs for them to
discover it)
If anyone else wants to check this version out, it is at:
git [..] ...:~drewm1980/orocos-toolchain/ocl_highwind.git
I also sent it as a merge request within gitorious.
The patch just adds the following to the deployer shell script:
MAGIC_FILE_NAME=.rtt_component_path
scan_dir()
{
if [ `find "$x" -maxdepth 1 -name $MAGIC_FILE_NAME` ]
then
for p in `cat "$x"/$MAGIC_FILE_NAME`
do
export RTT_COMPONENT_PATH=${RTT_COMPONENT_PATH}:$x/$p
done
break;
fi
}
x=$cwd
scan_dir
until [ "$x" == "/" ]
do
x=`dirname "$x"`
scan_dir
done
Cheers,
Andrew
New feature to make the deployer work better with version contro
Another new usability improvement: in my hacked deployer script I have
added the ability to make .ops scripts executable in linux by adding:
#!/usr/bin/env deployer
at the top (and doing chmod +x on them). This eleminates the need for
a trivial wrapper shell script to run the deployer in many cases, and
is of course still compatible with using such a shell script.
If anyone is interested, please give it a try. I have attached my
version of deployer script, but the canonical version lives here:
git [..] ...:~drewm1980/orocos-toolchain/ocl_highwind.git
So far it works for my use cases, but is possible it needs to be
modified to work for some other common use case.
The main thing that was needed was for the deployer to accept an .ops
file passed as an argument ~without the "-s" flag. In other words,
you can just run:
deployer foo.ops
and it will actually run the .ops script like you would expect.
Cheers,
Andrew
On Fri, Nov 23, 2012 at 11:13 PM, Andrew Wagner
<andrew [dot] wagner [..] ...> wrote:
> Dear Peter and the other Orocos Devs,
>
> As part of my crusade to make our flight code easier to install, I
> have extended the deployer wrapper script so that it searches up the
> directory hierarchy for a file with a special name (currently
> .rtt_componont_path), and adds any lines in it to RTT_COMPONENT_PATH.
> This file can then be added to the root of a git repository.
>
> This makes it far easier to ship code that does NOT require the user
> to set up any environment variables, as long as they run the deployer
> from anywhere in the shipped code (git repository). It also makes it
> easier to switch between multiple clones of repositories containing
> components (i.e. the deployer will use the components corresponding to
> the repo you have cd'd into).
>
> Please let me know if any changes are necessary to get this change
> mainlined. I would prefer not to have to maintain a separate branch
> of ocl for something so trivial, and others might find it useful
> (although something will have to be added to the docs for them to
> discover it)
>
> If anyone else wants to check this version out, it is at:
>
> git [..] ...:~drewm1980/orocos-toolchain/ocl_highwind.git
>
> I also sent it as a merge request within gitorious.
>
> The patch just adds the following to the deployer shell script:
>
> MAGIC_FILE_NAME=.rtt_component_path
> scan_dir()
> {
> if [ `find "$x" -maxdepth 1 -name $MAGIC_FILE_NAME` ]
> then
> for p in `cat "$x"/$MAGIC_FILE_NAME`
> do
> export RTT_COMPONENT_PATH=${RTT_COMPONENT_PATH}:$x/$p
> done
> break;
> fi
> }
> x=$cwd
> scan_dir
> until [ "$x" == "/" ]
> do
> x=`dirname "$x"`
> scan_dir
> done
>
> Cheers,
> Andrew
New feature to make the deployer work better with version contro
Hi Andrew,
On Sat, Nov 24, 2012 at 3:44 PM, Andrew Wagner
<andrew [dot] wagner [..] ...> wrote:
> Another new usability improvement: in my hacked deployer script I have
> added the ability to make .ops scripts executable in linux by adding:
>
> #!/usr/bin/env deployer
Why not:
#!/usr/bin/env deployer -s
?
>
> at the top (and doing chmod +x on them). This eleminates the need for
> a trivial wrapper shell script to run the deployer in many cases, and
> is of course still compatible with using such a shell script.
>
> If anyone is interested, please give it a try. I have attached my
> version of deployer script, but the canonical version lives here:
>
> git [..] ...:~drewm1980/orocos-toolchain/ocl_highwind.git
>
> So far it works for my use cases, but is possible it needs to be
> modified to work for some other common use case.
>
> The main thing that was needed was for the deployer to accept an .ops
> file passed as an argument ~without the "-s" flag. In other words,
> you can just run:
>
> deployer foo.ops
>
> and it will actually run the .ops script like you would expect.
Thanks for your improvements, I think we'll be able to merge most/all of it.
Peter
New feature to make the deployer work better with version contro
On Sat, Nov 24, 2012 at 5:15 PM, Peter Soetens <peter [..] ...> wrote:
>> Another new usability improvement: in my hacked deployer script I have
>> added the ability to make .ops scripts executable in linux by adding:
>>
>> #!/usr/bin/env deployer
>
> Why not:
>
> #!/usr/bin/env deployer -s
Because then linux lumps "deployer -s" into a single parameter and
passes it to env. I consider this bad design, but I suspect it is one
of those things that has been around for so long that people are
afraid to fix it, like misspellings in the names of some of the
syscalls.
http://en.wikipedia.org/wiki/Shebang_(Unix)
One downside I have found with the shebang is that we were setting the
log level in the shell script wrappers. Is there a way to set the log
level in the .ops script?
>> at the top (and doing chmod +x on them). This eleminates the need for
>> a trivial wrapper shell script to run the deployer in many cases, and
>> is of course still compatible with using such a shell script.
>>
>> If anyone is interested, please give it a try. I have attached my
>> version of deployer script, but the canonical version lives here:
>>
>> git [..] ...:~drewm1980/orocos-toolchain/ocl_highwind.git
>>
>> So far it works for my use cases, but is possible it needs to be
>> modified to work for some other common use case.
>>
>> The main thing that was needed was for the deployer to accept an .ops
>> file passed as an argument ~without the "-s" flag. In other words,
>> you can just run:
>>
>> deployer foo.ops
>>
>> and it will actually run the .ops script like you would expect.
>
> Thanks for your improvements, I think we'll be able to merge most/all of it.
>
> Peter
Thanks! Let me know if you want me to fix anything, or rebase, or
extend anything. In particular, I think the format for the
.rtt_component_path is pretty rigid now. Also, if you think you will
want to change that file name, it is better to do so before mainlining
the changes.
For better or worse, these changes are only affecting the unix users,
but I figure they can at least be prototypes for behavior that is
ultimately ported into portable C++.
Cheers,
Andrew