[prev in list] [next in list] [prev in thread] [next in thread] 

List:       orocos-dev
Subject:    [Orocos-Dev] [Bug 1019] Precedence of ROS packages over regular files when using the import function
From:       meyer () fsr ! tu-darmstadt ! de (Johannes Meyer)
Date:       2013-01-30 9:49:14
Message-ID: 20130130094914.22397.qmail () web01-shared04 ! priorweb ! be
[Download RAW message or body]


http://bugs.orocos.org/show_bug.cgi?id=1019

--- Comment #2 from Johannes Meyer <meyer at fsr.tu-darmstadt.de> 2013-01-30 10:49:14 CET ---
(In reply to comment #1)
> (In reply to comment #0)
> > Created attachment 851 [details] [details]
> > swapping the different checks in RTT::ComponentLoader::import()
> > 
> > I would like to propose the attached patch for the RTT::ComponentLoader class
> > which solves the following problem when using the import(package) operation in
> > the deployer: If there is a file in the current working directory with the same
> > name as the package I would like to import, the old behaviour was to load that
> > file directly and abort with an error without trying the other variants (ROS
> > package or installed package).
> > 
> > A simple example: I have a ROS package named "foo" with some dependencies
> > defined in its manifest.xml file and a script bin/foo which launches the
> > executable bin/foo-gnulinux with a proper environment and a couple of command
> > line options. In the deployer script I call import("foo") to load component
> > libraries in package foo and all dependent packages. Without the patch, the
> > method call fails with an error message saying that "foo" is not a valid
> > component library.
> > 
> > In theory, the is_regular_file check in ComponentLoader.cpp should be moved
> > after the importInstalledPackage() call to also be able to import installed
> > packages named "foo" in the example case, but importInstalledPackage() does not
> > fail silently, causing ugly error message if you really want to import regular
> > files.
> 
> I understand, but it's quite an ambiguity to have a package name in your path
> and the same file name in your CWD. The same holds for the ROS case imo, but I
> agree that the patch is an improvement from a usability perspective.

What is the problem with having an executable with the same name as a package
in the CWD? In the ROS world, it is not unusual to have small packages with
only a single executable with the same name as the package (e.g. rviz,
rostopic). If they were dedicated import functions for libraries, paths and
packages, there were no ambiguities to deal with.

IMHO, the smart all-in-one import function should consider all possible options
and only emit an error, if either no option matches or if they are real
ambiguities. The case where a regular file has the same name as a package could
also be resolved by additionally looking at the extension. I guess adding an
isLoadableLibrary(arg) check in ComponentLoader.cpp:356 instead of changing the
order of the checks would also solve this issue.

> 
> > 
> > By the way, which is the correct git branch to work on for 2.6? master or
> > toolchain-2.6?
> 
> toolchain-2.6. Once Charles' work is done, I'll merge his work to master, merge
> some other queued patches which change the ABI and then release 2.7.
> 
> Peter

Thanks, Johannes

-- 
Configure bugmail: http://bugs.orocos.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.

[prev in list] [next in list] [prev in thread] [next in thread]