This is the mail archive of the
automake-prs@sources.redhat.com
mailing list for the automake project.
automake/440: Spaces in path where automake runs cause errors
- From: automake-bug-2004 at ryandesign dot com
- To: automake-gnats at sources dot redhat dot com
- Date: 30 Nov 2004 23:25:44 -0000
- Subject: automake/440: Spaces in path where automake runs cause errors
- Reply-to: automake-bug-2004 at ryandesign dot com
>Number: 440
>Category: automake
>Synopsis: Spaces in path where automake runs cause errors
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: tromey
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Nov 30 23:31:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator: automake-bug-2004@ryandesign.com
>Release: ???
>Organization:
>Environment:
>Description:
If there are spaces in the path of the directory where autoconf runs, then errors are generated. See this bug report for an example:
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1066260&group_id=1645
>How-To-Repeat:
>Fix:
The SourceForge bug I linked to has a link to a mailing list discussion, in which it is stated that autoconf / automake do not, cannot, and will not work with spaces in the path. This may have been acceptable when this software was used only by geeks with UNIX / Linux systems, but now that Mac OS X is BSD-based, a lot more users are going to be using this software who have quite different expectations of software. Mac users expect software to work the way they want it to. So, when I want to name my directory with spaces in it, then my I expect my software to continue to work. It's that simple. So autoconf / absolutely must support spaces (and any other weird characters I might want to insert) in pathnames.
Since the email discussion I ran across suggests that autoconf / automake cannot use spaces because of some very fundamental design decisions which would make it very difficult or impossible to change at this point, the other solution would be to have autoconf / automake test, as the first thing in the configuration / making process, whether the directory name has unacceptable characters in it, and if so to provide an error message to that effect and then exit. That would be infinitely more helpful than the misleading messages that are currently produced in this situation.
>Release-Note:
>Audit-Trail:
>Unformatted: