For more infomation about this bug, visit
Summary: XML Include statement does not 'go into' included dir
Product: OCL
Version: trunk
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Deployment
AssignedTo: orocos-dev [..] ...
ReportedBy: peter [dot] soetens [..] ...
CC: orocos-dev [..] ...
Estimated Hours: 0.0
Created an attachment (id=327)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=327)
Fixes this bug
When writing in a deployment XML file an include statement like
The XML parser does not descend into the ../../common/ directory and
interpretes the Import statements in the common.xml file in the current
directory instead of in ../../common
This is practically very inconvenient as the common.xml file can be included
from different directories, hence it would need to 'adapt' to all these
different paths.
The solution is to 'chdir' into the ../../common and do imports relative to
that directory. See the small attached patch.
Any objections ?
[Bug 572] New: XML Include statement does not 'go into' included
> Created an attachment (id=327)../../common/common.xml
> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=327)
> Fixes this bug
>
> When writing in a deployment XML file an include statement like
>
>
> The XML parser does not descend into the ../../common/ directory and
> interpretes the Import statements in the common.xml file in the
> current
> directory instead of in ../../common
>
> This is practically very inconvenient as the common.xml file can be
> included
> from different directories, hence it would need to 'adapt' to all
> these
> different paths.
>
> The solution is to 'chdir' into the ../../common and do imports
> relative to
> that directory. See the small attached patch.
>
> Any objections ?
I presume it backs out the chdir when it leaves an include. So the
following holds for nested includes?
** xxx.xml **
include a/yyy.xml <-- chdir to a then read yyy
** yyy .xml **
include b/zzz.xml <-- chdir to b so now in "a/b"
** end of yyy.xml
** back in xxx.xml **
include aaa.xml <-- picks up out of ".", same dir as "xxx.xml"
Does this do a chdir into config?
deploy --start config/a.xml
S
[Bug 572] New: XML Include statement does not 'go into' included
On Friday 13 June 2008 15:21:52 S Roderick wrote:
> I presume it backs out the chdir when it leaves an include. So the
> following holds for nested includes?
Yes, it stores the current dir on the stack before entering a new one, and
unwinds the stack again when done reading an xml message.
>
> ** xxx.xml **
> include a/yyy.xml <-- chdir to a then read yyy
>
> ** yyy .xml **
> include b/zzz.xml <-- chdir to b so now in "a/b"
> ** end of yyy.xml
>
> ** back in xxx.xml **
> include aaa.xml <-- picks up out of ".", same dir as "xxx.xml"
yes.
>
>
> Does this do a chdir into config?
>
> deploy --start config/a.xml
No. I wonder if we should. In our current use cases, we assume it doesn't. For
example:
app/
app/cpf
app/cpf/config.xml # <-- this file is in version control
app/cpf/include.xml # <-- idem + is included by config.xml
app/build
app/build/component
app/build/component/libmycomp.so # <-- this file was compiled
We would fire up the deployer from the build directory with:
deployer-gnulinux -s ../cpf/config.xml
config.xml would import "component" (not "../build/component")... Also
include.xml would assume it was sourced from the build directory.
Both cases are actually worse off with this patch.
The use case changes when the XML file is 'installed' with the components
somewhere:
inst
inst/lib
inst/lib/cpf
inst/lib/cpf/mycomp.xml # <-- imports "../libmycomp.so"
inst/lib/libmycomp.so
If we now include "inst/lib/cpf/mycomp.xml" from the app/cpf/config.xml file
above, we would like to have the 'chdir' behaviour. I don't know if this is a
common case, having the xml file installed with the component library.
So if we keep our xml files locally with our build, the include directive is
worse, if we include system-level xml files, it is necessary.
The same reasoning applies to loading scripts and property files for the
components. They might be installed with the component, or they might be
located where the user starts the deployer... This patch does not fix this
issue.
The distinction looks very similar to the "C" #include directive having ""
(local) versus <> (global).
Peter