[bug #23468] end-of-line backslashes fails with perl (Cygwin, although I strongly believe it's general problem)

[anonymous]

Follow-up Comment #1, bug #23468 (project make):

Look in the NEWS file:

* WARNING: Backward-incompatibility!
  In order to comply with POSIX, the way in which GNU make processes
  backslash-newline sequences in command strings has changed.  If your
  makefiles use backslash-newline sequences inside of single-quoted
  strings in command scripts you will be impacted by this change.  See
  the GNU make manual subsection "Splitting Command Lines" (node
  "Splitting Lines"), in section "Command Syntax", chapter "Writing the
  Commands in Rules", for details.

This is a feature, not a bug.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: autoconf-2.62: `make install' fails if file system is case insensitive

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[adding bug-automake and bug-make; this is
http://lists.gnu.org/archive/html/bug-autoconf/2008-05/msg0.html]

According to Keith Marshall on 5/9/2008 2:16 PM:
| If autoconf's Makefile is processed by a GNU make-3.81, which has been
| configured to respect a case insensitive file system, (IMO, the correct
| configuration for use on MS-Windows, among other other systems which
| also have such file systems), and the build is configured directly
| within the source directory, then `make install' fails thus:
|
|   $ make install
|   Makefile:678: warning: overriding commands for target `install'
|   Makefile:574: warning: ignoring old commands for target `install'
|   /bin/sh /home/rgbl0264/foobar/foo/autoconf-2.62/build-aux/missing \
|   --run makeinfo --no-headers --no-validate --no-split  -o install \
|   ./doc/install.texi

Looking further at this, what happens with your case-insensitive make when
running 'make dist' on a project built with 'automake --gnu'?  There,
automake adds an automatic dependency on all 'dist*' targets to unadorned
INSTALL.  Does that mean that 'make dist' will attempt to install the
package when run on MSYS?  Will it just be a no-op because the file
INSTALL already exists?  Is this something that automake needs to address,
by outputting $(abs_srcdir)/INSTALL rather than plain INSTALL in the
dependencies of distdir?

|
| This problem was recently reported by a user on the MinGW users ML:
| http://thread.gmane.org/gmane.comp.gnu.mingw.user/26315
|
| It is not apparent when performing a VPATH build, but is reproducible
| when building in the source directory, both for autoconf-2.62, and for
| earlier versions, (I've also confirmed this for autoconf-2.61).

Because in a VPATH build, $(srcdir)/INSTALL is different than ./INSTALL,
and it looks like case-insensitive GNU make is treating 'make install' and
'make ./INSTALL' as synonyms.  Maybe this is also something that should be
addressed in GNU make, as case-insensitivity makes following GNU Coding
Standards rather difficult?  GNU Coding Standards require the existence of
both 'make install' and './INSTALL'.

|
| This issue may be resolved by replacing each of the three references to
| `$(srcdir)/INSTALL', in the Makefile, by `$(abs_srcdir)/INSTALL'.  I've
| confirmed this, by making the appropriate changes in Makefile.in, and
| then successfully repeating the `./configure && make && make install'
| sequence under MSYS-1.0.11, (with case-insensitive GNU make-3.81), in
| the autoconf-2.62 source directory, on MS-Win2K.  The attached patch,
| against released autoconf-2.62's Makefile.am, will introduce the same
| change, on next Makefile.in regeneration.

That worked for 'make install', but broke 'make dist'; I'm trying to
figure out whether adding:

INSTALL: $(abs_srcdir)/INSTALL

to autoconf's Makefile.am will be making the problem any worse (at least
it fixes the 'make dist' regression when using the normal case-sensitive
GNU make).  Maybe the short answer is that on MSYS (or anywhere else with
case-insensitive GNU make), you should not expect 'make dist*' to work.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhFlgIACgkQ84KuGfSFAYB1ygCfUvdwoLNeVI3ra4TMb0A1d9m4
YFwAn0m/eukAKMi7LuxKb7wKhidq6yzq
=C2vT
-END PGP SIGNATURE-


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #23468] end-of-line backslashes fails with perl (Cygwin, although I strongly believe it's general problem)

[Paul D. Smith]

Update of bug #23468 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

As Anonymous points out, this is a change that was required for POSIX
conformance.

Note you can overcome this by putting your long perl script in a make
variable; instead of:

foo:
perl -e 'my multi-
line perl script'

you can use something like:

PERL_SCRIPT = my multi-
 line perl script
foo:
perl -e '$(PERL_SCRIPT)'

The latter will work the same in all versions of make, and is arguably easier
to read and understand as well.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make