Re: allow convenient library in subdirectory

[Tim Van Holder]

>  Tim> Well, as I understand it automake needs very few changes to work
>  Tim> on my system (DOS box under WinME), so I figured it was already
>  Tim> DOS-friendly where it counted.
> 
> Hmm... my DOS/Windows inexperience shows off.  I thought that
> some work would be needed to turn the slashes embeded in the
> Makefiles into back-slashs at some point (config.status).
> Obviously (from your comment) it works as is.

Well, that's thanks to DJGPP, not DOS - our libc accepts both forward and
backward slashes, and so does our port of make.

> This leads me to two other questions: 
> 
>   - Does your comment apply to (plain) MS-DOS too?  (I'm aware
>     that Windows accepts Unix-style filenames, but does it still
>     stand for DOS?  So far I believed it was not the case.)

No, neither DOS nor non-NT Windows support forward slashes; it's our
libc that does.  As long as the filenames only go through DJGPP-based
commands, there's no problem.  Only the shell has some issues (while it
can accept both slash styles, backslashes have special meaning and
require quoting).  And if DOS/Windows commands are used in makefiles,
the slashes must be flipped to DOS mode.  This is not usually a problem
for automake, as it is mainly used for packages that originated on
Unixy systems; automake _might_ need special machinery to support native
DOS packages.

All this is basically helped along by our libc; on OS/2, all this is
not true, as its libc apparently does not support both styles (that, or
package ports for OS/2 haven't been similarly updated).

>   - Since Windows accepts slashes, and Unices do not accept
>     backslashes, shouldn't Automake constraint the programmer to
>     use the portable way? (i.e. banning backslashes)

Well, yes - but as noted above, Windows does not, of itself, support
forward slashes.  Plus, I think we don't want automake to be "restricted"
to portable apps; it's still quite a useful tool for packages that only
support a single system.