On Mon, 2006-12-11 at 01:16 +0100, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Sun, 2006-12-10 at 11:21 +0100, Jan Kiszka wrote:
> >> The only part of the Xenomai user-space package not yet following
> >> standard installation rules is the testsuite. It gets installed to
> >> $prefix/testsuite, by default /usr/testsuite. The attached patch is an
> >> approach to overcome this unusual layout.
> > 
> > Ack. Implementation-wise, we have to fix the following though:
> > 
> > xeno-load.in needs to be fixed, so that passing a single dot as argument
> > correctly picks the default runinfo target in the current directory.
> > This currently does not work as expected.
> [obviously now fixed in svn]
> > 
> > The second patch works around a problem with sudo relying on the
> > contents of the user's PATH variable. This won't work for people using a
> > version of sudo compiled with the secure path option by their favourite
> > distro. In that case, /usr/xenomai/bin (or whatever the user picked to
> > install xenomai) won't appear in that secure path, so the binary program
> > given in the runinfo file won't be found. A possible option is to
> > provide a relative path to locate the binary program,
> > e.g. ../../../../bin/latency for the latency test, as the example patch
> > shows. Not pretty, but the other way would need to autoconfiscate the
> > runinfo files, or at least run them through sed before installing, so
> > that we could substitute some placeholder with $exec_prefix.
> Relative paths are not fully safe, 

Why, provided the sudo sub-shell in xeno-load changes dir to the
target_dir variable contents?


Xenomai-core mailing list

Reply via email to