2007-04-20

There is only one right include strategy

There is only one right way of the implementation of searching of included files. In case if include contains a relative path it should be relative to the folder where the inclusive file is placed. Actually, it is so in C/C++.

Either I do not understand something, or Nant has surprised me
Let's take the following folders structure:

./
a/
a.build
all.build
common.build

I'd like to build project «a» if I'm located at folder «a» and if I'm in the root I'd like to build all projects.
The situation has become complicated because of the common file common.build which contains required useful settings.

At a first sight nant includes files relative to a current working directory (basedir project attribute)

The contents of a.build file

<project name="all" basedir="..">
<include buildfile="common.build"/>
<echo message="building a type - ${type}"/>
<echo message="base-dir ${project::get-base-directory()}"/>
</project>


The contents of all.build file

<project name="all" basedir=".">
<include buildfile="common.build"/>
<include buildfile="a/a.build"/>
<echo message="building all type - ${type}"/>
</project>


Run a.build being in folder a - everything is cool.

Being in the folder with the file all.build - run:

NAnt 0.85 (Build 0.85.2478.0; release; 14.10.2006)
Copyright (C) 2001-2006 Gerry Shaw
http://nant.sourceforge.net

Buildfile: file:///D:/Temp/2007-04-19/all.build
Target framework: Microsoft .NET Framework 2.0


BUILD FAILED

D:\Temp\2007-04-19\a\a.build(3,7):
Build file 'D:\Temp\2007-04-19\a\common.build' does not exist.

Total time: 0 seconds.


I have the impression that files included in the main file are searched relative to the working directory, but the files included into included files are searches relative to the inclusive file.

No comments:

Post a Comment