ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kuiper, Arnout" <Arnout.Kui...@nl.origin-it.com>
Subject RE: Path & dir separators (was Re: Ant Principles)
Date Wed, 19 Apr 2000 15:36:57 GMT
> From: Michael Smith [mailto:michael@sneakerlabs.com]
> Actually, since you're talking about the Windows world, you 
> can have UNC
> path names.  The //c/foo/bar would conflict with a UNC path 
> referring to a
> file 'bar' in the share 'foo' on computer 'c'.  

You're so right...

> So far, here's what I think we can all agree on:
> 
>  - A developer on a windows platform prefers to use ; and \ 
> as the path 
>    and directory separators and desires the ability to use UNC names
>    and drive letters followed by colons.  A unix platform developer 
>    may prefer to use : and / (and doesn't care about UNC 
> names and drive
>    letters).  Mac developers would prefer to use whatever 
> separators are
>    used on the mac platform.
> 
>  - The build file should be portable to other platforms, but in some
>    cases it doesn't need to be.
>  
>  - It would be nice to support absolute paths, even for a 
> build that must 
>    be made on multiple platforms

Agreed, although I think that support for absolute paths in a
multi-platform environment is a nice to have feature, but not at
all costs (both internal and external complexity). As you'll see
below, the build-file will become a lot more complex.

> To allow developers to use the separators that they are 
> accustomed to on
> their platform, Ant would add two optional attributes to the 
> project element
> in the XML file -- one specifying the path separator and one 
> specifying the
> directory separator.  Then, all path and dir separators that 
> appear in the
> build file are interpreted based on the ones specified as 
> attributes to the
> project element.  If an attribute is omitted, the default for 
> the local
> platform is used.

[snip]

I think this is the best idea until now on the path/dir separator
issue. So +1 for me.

> So far, I have assumed that the directory and path separators 
> are consistent
> throughout the entire build file.  While in most cases this 
> will be true, it
> would be nice to support different separators within the same 
> file.  Why you
> might ask?  For absolute paths. A build file may rely on 
> absolute paths to
> build properly, and the absolute paths on windows and unix 
> filesystems are
> specified differently.  
> 
> To solve this problem, I am relying on the usage of the path 
> definition
> stuff proposed by Thomas Haas.  In the "element" and "path" 
> elements that
> are used to define a bath, a "pathseparator" and 
> "dirseparator" attribute
> are optionally added.  (note:  the pathseparator is meaningless in the
> "element" element, as it specified only one path element).  
> The attributes
> specified on the path element would override any specified at 
> the project
> level.    
> 
> For example, consider the following build file created for 
> building on a
> unix platform:
> 
> <project>
>   <!-- [snip] -->
>   <somepath>
>    <element location="../classes" />
>    <path definition="/usr/local/classes:/usr/local/classes/foo.jar" />
>   </somepath>
>   <!-- [snip] -->
> </project>
> 
> You could make this "portable" to run under Windows by 
> changing it to the
> following:
> 
> <project dirseparator="/" pathseparator=":">
>   <!-- [snip] -->
>   <somepath>
>    <element location="../classes" />
>    <path definition="/usr/local/classes:/usr/local/classes/foo.jar" />
>   </somepath>
>   <!-- [snip] -->
> </project>
> 
> However, while this build file is portable, the build itself 
> isn't portable
> because of the absolute paths are not going to be found on a windows
> platform.  Using the path level separators, you would add the 
> following to
> get the build to work on a Windows platform:
> 
> <project dirseparator="/" pathseparator=":">
>   <!-- [snip] -->
>   <somepath>
>    <element location="../classes" />
>    <path definition="/usr/local/classes:/usr/local/classes/foo.jar" />
>    <path definition="D:\libs;D:\libs\foo.jar" 
>          dirseparator="\" pathseparator=";" />
>   </somepath>
>   <!-- [snip] -->
> </project>
> 
> Now, the absolute paths will be found on both windows and 
> unix platforms
> with only one drawback -- there will be extraneous path 
> information added. 
> When on a Unix platform, the paths D:/libs and 
> D:/libs/foo.jar will be added
> (they most likely do not exist), and on the windows platform, 
> the paths
> \usr\local\classes and \usr\local\classes\foo.jar will be 
> added (which also
> are unlikely to exist).
> 
> To remove this potential problem, another attribute can be 
> added to the
> "path" and "element" elements that specify which platform 
> they should be
> added on (very similar to the "os" attribute in the exec 
> taskdef).  This
> portable build file would then become:
> 
> <project dirseparator="/" pathseparator=":">
>   <!-- [snip] -->
>   <somepath>
>    <element location="../classes" />
>    <path definition="/usr/local/classes:/usr/local/classes/foo.jar" 
>          os="unix"/>
>    <path definition="D:\libs;D:\libs\foo.jar" 
>          os="win" dirseparator="\" pathseparator=";" />
>   </somepath>
>   <!-- [snip] -->
> </project>
> 
> Then, the path that is built will be 
> On unix:
> ../classes:/usr/local/classes:/usr/local/classes/foo.jar
> 
> On windows:
> ..\classes;D:\libs;D:\libs\foo.jar
> 
> 
> We now have a truely portable build file that will work on 
> unix and windows
> and includes absolute paths.  To get the build working on a 
> mac, you would
> probably need to add path elements to point to foo.jar -- 
> although if you
> had just relied on relative paths, your life would have been 
> easier... :)

It's a good idea, but doesn't it make the build-file too complex?
(Not to mention Ant itself). How is the OS name determined? "unix"
is not a OS name, but a collection of different OSs.

Let's recap:

For the user on a single platform:
- Just use the path/dir separators of the platform in the paths
  in the build-file.

For the user on multiple platforms without absolute paths:
- Specify the separators in the project element
- Use these path/dir separators in your paths in the build-file.

For the user on multiple platforms with absolute paths:
- Specify the separators in the project element
- Use these path/dir separators in your paths in the build-file.
- For each absolute path, use the construct where you can set
  the path based on the platform.

I assume here that the simple path declarations like

  <copydir src="build" dest="../lib/dist"/>

are still possible (thus without using the path construct).

So for the most complex situation we would get (assuming the OS name
issue has been resolved):

  <copydir>
    <src>
      <path definition="c:\foo\bar"
          os="win" dirseparator="\" pathseparator=";"/>
      <path definition="/usr/local/foo/bar" 
          os="unix" dirseparator="/" pathseparator=":"/>
    </src>
    <dest>
      <path definition="d:\xyz"
          os="win" dirseparator="\" pathseparator=";"/>
      <path definition="/home/xyz" 
          os="unix" dirseparator="/" pathseparator=":"/>
    </dest>
  </copydir>

Is this all correct?

If so, I think it is a good proposal, but we should come up
with a way to that prevent tasks from being bother by complex
path constructs. How about having a "Path" type which can be
processed by the reflector in the Ant core? Then the tasks
just need the setSomePath/addSomePath methods, and Ant itself
takes care of the rest.

Cheers,

  Arnout

Mime
View raw message