On Mon, 2006-12-11 at 10:24 +0100, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > 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?
> Because exec_prefix (=>bindir) may be different from prefix
> (=>pkgdatadir), thus there is no fixed relation between the .runinfo
> location and the binaries until after the installation.
Xenomai-core mailing list