From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <457EAACF.3060307@domain.hid> Date: Tue, 12 Dec 2006 14:12:47 +0100 From: Gilles Chanteperdrix MIME-Version: 1.0 Subject: Re: [Xenomai-core] [PATCH] consolidate testsuite installation References: <457BDF99.1020405@domain.hid> <1165778549.8255.17.camel@domain.hid> <457CA36C.5060805@domain.hid> <1165828053.5025.8.camel@domain.hid> <457D23CA.0@domain.hid> <457E6A01.4090500@domain.hid> <457EA179.5070606@domain.hid> In-Reply-To: <457EA179.5070606@domain.hid> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: xenomai-core Jan Kiszka wrote: > Gilles Chanteperdrix wrote: > >>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. >> >>Since the testsuite scripts are supposed to be run on the target, I >>think they should be installed under exec_prefix. >> > > > I didn't come across some scenario yet where I had to split exec_prefix > from prefix. So I followed this definition: > > "Generally, $(exec_prefix) is used for directories that contain > machine-specific files (such as executables and subroutine libraries), > while $(prefix) is used directly for other directories." > > As the scripts just like the .runinfos are certainly > machine-independent, my feeling is that prefix is the right thing. At some point in time: https://mail.gna.org/public/xenomai-help/2006-09/msg00181.html I started to use exec_prefix and prefix for separating the binaries, libraries and script that need to be installed on the target from the include files, documentation and xeno-config script that need to be installed on the host. -- Gilles Chanteperdrix