facepalm: install fails because $(PREFIX)/lib already exists

[sgbeal]

install fails because $(PREFIX)/lib already exists

[stephan@host:~/cvs/libsass]$ m install PREFIX=$HOME
mkdir /home/stephan/lib
mkdir: cannot create directory ‘/home/stephan/lib’: File exists
Makefile:263: recipe for target '/home/stephan/lib' failed
make: *** [/home/stephan/lib] Error 1

The fix is trivial: use mkdir -p instead of mkdir.

This is the same as #1992, but that ticket is inexplicably closed.

PS: when trying to use the autotools-generated build, by running autoconf to convert configure.ac to configure, the resulting ./configure fails because:

[stephan@host:~/cvs/libsass]$ ./configure --prefix=$HOME
configure: error: cannot find install-sh, install.sh, or shtool in script "."/script

Thus i'm using the makefile which is checked in to the tree, rather than the one generated by autotools (a.k.a. GNU "Auto, my ass!" Tools).

[xzyfer]

Using mkdir has come up multiple times and been rejected because it is not portable. We're open to solution that are portable.

…

On Mon., 12 Nov. 2018, 6:55 pm Stephan Beal ***@***.*** wrote: install fails because $(PREFIX)/lib already exists ***@***.***:~/cvs/libsass]$ m install PREFIX=$HOME mkdir /home/stephan/lib mkdir: cannot create directory ‘/home/stephan/lib’: File exists Makefile:263: recipe for target '/home/stephan/lib' failed make: *** [/home/stephan/lib] Error 1 The fix is trivial: use mkdir -p instead of mkdir. This is the same as #1992 <#1992>, but that ticket is inexplicably closed. PS: when trying to use the autotools-generated build, by running autoconf to convert configure.ac to configure, the resulting ./configure fails because: ***@***.***:~/cvs/libsass]$ ./configure --prefix=$HOME configure: error: cannot find install-sh, install.sh, or shtool in script "."/script Thus i'm using the makefile which is checked in to the tree, rather than the one generated by autotools (a.k.a. GNU "Auto, my ass!" Tools). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2727>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjZWC46FJREYZk3iPIdWpGiuKuKlkJ4ks5uuSlkgaJpZM4YZIEz> .

[sgbeal]

Certainly mkdir -p is more portable than simply failing to install on any platform at all?

[sgbeal]

Here's a portable solution, taken from the autotools manual:

From the libsass checkout:

autoreconf --install
...
configure.ac:15: installing 'script/install-sh'
...
[stephan@host:~/cvs/libsass]$ l ./script/install-sh
-rwxr-xr-x 1 stephan stephan 15155 Nov 12 10:07 ./script/install-sh

That install script is as portable as it gets. (Simply throw away all of the autoreconf output aside from that file, then check that file in.)

Funnily enough, it uses mkdir -p (which is apparently specified by POSIX mkdir), but it also works around various portability problems.

[sgbeal]

Apropos portability: the source code uses C++0x, which means it's compiling on a relatively recent platform (less than 10 years old). i'd bet my left testicle that all such platforms support mkdir -p.

[xzyfer]

Everything has been explained in detail multiple times in all the previous closed issues. We'll consider a pr that address the concerns that have previously been raised.

…

On Mon., 12 Nov. 2018, 8:13 pm Stephan Beal ***@***.*** wrote: Apropos portability: the source code uses C++0x, which means it's compiling on a relatively recent platform (less than 10 years old). i'd bet my left testicle that all such platforms support mkdir -p. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2727 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjZWDztL9XVhyClKwxTr7QVoEu2Oie3ks5uuTvQgaJpZM4YZIEz> .

[glebm]

@xzyfer Can you please link to the closed issue? #1992 doesn't discuss it.

I'd like to read the discussion to understand the claims of non-portability, because mkdir -p support is a POSIX requirement: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mkdir.html

[sgbeal]

What perceived limitation is not addressed by using the install script generated by autoconf (demonstrated 4 comments up from here)? This project uses the autotools, and is thereby limited in portability to platforms that toolset supports. Using autotool's install script is therefore the most natural and portable solution for all platforms the project can be built on using the provided makefiles.

[glebm]

@sgbeal While I still can't find the issue, looking further at the Makefile, it appears to support Windows. On Windows, mkdir is an alias for md, which does not support -p.

Perhaps send a PR that sets MKDIR differently on Windows vs non-Windows?

[xzyfer]

Plenty details below. I'm not well versed on the problem but I've seen it come up over and over again.

#795 (comment)
#2486
#2109
#1433
#1365 (comment)

[sgbeal]

@glebm what's a "Windows"?

The build uses the autotools and it "really should" use the install-sh which is distributed with autotools. If that installer is not portable enough then using the autotools is a lost cause.

[glebm]

@sgbeal The checked in Makefile is not generated by autotools. It's an alternative way to build for when autotools may not be available (e.g. when compiling this for a C extension for Ruby or Python).

"Windows" in this case is when you have e.g. gcc and gmake but are running it from CMD (as opposed to e.g. Cygwin Bash or a similar POSIX environment).

Regardless, I think my #2728 PR resolves this issue, as with that PR make should no longer attempt to create directories that already exist.

[glebm]

@xzyfer Thanks! Looks like I guessed right that this is specifically about Windows compatibility. Sent #2728 which should simply prevent make from trying to create directories that already exist.

[sgbeal]

@glebm my sincere apologies: 'what's a "Windows"' was intended facetiously (Windows hasn't been a thing in my household since last millennium), not as as an honest question, and that has no place in this forum.