RE: [PATCH 2/2] Do not use DOS paths on Cygwin

[Pavel Fedin]

 Hello!

> This is what I'd expect.

 Good then.

> > 2. PATH_SEPARATOR on Cygwin is ':' and on pure DOS/Windows is ';'.
> 
> This is true, but how is this relevant to the issue at hand?
> 'abspath' does not deal with PATH-style directory lists, it accepts a
> single file name as its argument.  What am I missing here?

 To the issue - no, this really doesn't relate. But this is still involved
in the change, because path list is one more thing which depends on native
path style of underlying environment.

> It probably would, if you do a clean job, but frankly I'm not sure it's
> worth your while.  It is so easy to glean this information by just
> looking at the appropriate preprocessor macro, like WINDOWS32 etc. that
> a configure-time test sounds like overkill.

 Yes, but there can be one thing, considering MinGW. If you don't know,
MinGW actually consists of two environments: MinGW by itself and MSYS. MinGW
by itself is a pure Windows environment. MSYS is enlightened version of
Cygwin whose purpose is "to provide enough compatibility to run UNIX shell
scripts like configure". MinGW land uses DOS-style paths and MSYS land uses
UNIX-style ones. Consequently, they actually build two versions of make. One
version is called 'mingw-make' and is a pure Windows program. Another
version is called 'make' and operates in MSYS land, dealing with UNIX-style
paths and path lists. They do this because majority of build systems use
POSIX semantics. Both versions are built from the same source.
 Consequently, there should be a possibility to override "native path
format" test, similar to what Cygwin currently does to disable DOS paths.
This can be needed for building MSYS version.

 Ok, good, currently i already have an implementation which works fine on
Cygwin and passes all test suite. Now i want to try to build pure Windows
version and make sure that it at least doesn't become worse. I need some
time to test it and to approve the patch for submission here at Samsung.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia



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

[bug #39709] a few typos fixes

[Martin Dorey]

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

The patch looks good to me and I'm a picky native speaker.  My one not-really
quibble was why not also fix the "pattrn" targets in
tests/scripts/features/patspecific_vars.  I'm not seeing the reason why
"pattern" has to be avoided, but it's unfamiliar source operating in an
unfamiliar environment.

___

Reply to this item at:

  

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


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

[bug #39709] a few typos fixes

[anonymous]

URL:
  

 Summary: a few typos fixes
 Project: make
Submitted by: None
Submitted on: Tue 06 Aug 2013 08:55:48 PM UTC
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: Any
   Fixed Release: None
   Triage Status: None

___

Details:

A few misspell fixes. (found by https://github.com/vlajos/misspell_fixer)



___

File Attachments:


---
Date: Tue 06 Aug 2013 08:55:48 PM UTC  Name: 0001-typofixes.patch  Size: 5kB  
By: None



___

Reply to this item at:

  

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


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

Re: [PATCH] Use spawn() in GNU Make on Cygwin, updated

[Eli Zaretskii]

> From: Pavel Fedin 
> Cc: bug-make@gnu.org
> Date: Tue, 06 Aug 2013 10:46:51 +0400
> 
>  Runtime ??? I am sorry, but what's the sense ?

I tried to explain that in my first response: 'fork' has a certain
semantics and implements requirements that 'spawn' does not.  Since
Cygwin is a Posix environment and runs the Posix code in Make, users
generally expect it to follow the Posix semantics to the letter.
'spawn' will not in general do that 100%, although it is probably
close, at least in this case.

IOW, the default operation mode should always work correctly.  If it
is possible to speed it up without losing correctness, fine.
Otherwise, the fast version must be optional, and the option must be
selectable at run time, or else users will be unable to decidewhat
they want, unless they also build their own Make.

>  First, this will not work well, because many makefiles around call make
> recursively. And they will not necessarily pass over command line options.

Using "$(MAKE) $(MFLAGS)" is good practice that is seen in many
places.  We can expect that from users who want to invoke Make with a
non-default option.

> Well, it would be a little more convenient to have env variable, something
> like MAKE_USE_SPAWN, but anyway, what is the real purpose of keeping fork()
> ?

Environment variable would probably also be OK, if Chris agrees.

As for the purpose, see above: there must be a way for users to
request 100% correct, if slower, operation mode.

>  Additionally your proposal would mean LOTS of changes. Instead of several
> #ifdef's you would have both versions of code plus some extra conditions.

I realize that it is easier to use compile-time conditions, but I
don't think this will be acceptable.

> spawn() is a full equivalent of fork() + exec().

I'm not sure (Chris?).  In any case, you will see in the code that
Make does a few things between the calls to 'fork' and 'exec'.  How
can you be sure that 'spawn' does all that in exactly the same way?
And even if does that today, how can anyone be sure the Cygwin
maintainers will not change it one day to do things in a slightly
different way?

> gcc on Cygwin uses spawn() for running its components, and it works
> quite fine.

GCC and Make don't do the same and don't have the same code that deals
with subprocesses.  That this works in GCC is not in any way proof
that it will work in Make exactly like 'fork' does.

> (2) should also be safe and at least harmless.

I just don't know, and don't have EMX installed to test that.

> Well, if you really want it, changing child's environment can be
> #ifdef'ed.

Yes, please.

> However according to specification, spawnvpe() looks for the binary
> in current PATH, so on EMX the same thing should apply as on
> Cygwin. Well, it could work if EMX doesn't strictly follow POSIX
> semantics and implicitly considers current directory to be part of
> PATH (DOS/Windows-style behavior).

EMX is not a Posix environment, AFAIK.  And in any case, I don't want
to risk breaking a platform for which I'm not responsible and whose
functionality I cannot test.  I'm sure you understand.

>  OK, if you really-really don't care about what someone other than you
> think, can you accept last chunk of the patch for now (variable rename) ?
> This would decrease size of speedup patch which i will have to maintain.

You mean, rename 'status" to 'child_status'?  That's not a problem.

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

Re: [PATCH 2/2] Do not use DOS paths on Cygwin

[Eli Zaretskii]

> From: Pavel Fedin 
> Cc: m...@cgf.cx, bug-make@gnu.org
> Date: Tue, 06 Aug 2013 17:46:14 +0400
> 
> 1. abspath on Cygwin returns UNIX-style paths and on pure DOS/Windows -
> DOS-style.

This is what I'd expect.

> If DOS-style absolute path is already supplied, it will leave it as
> is.

Again, this is what I'd expect.

> 2. PATH_SEPARATOR on Cygwin is ':' and on pure DOS/Windows is ';'.

This is true, but how is this relevant to the issue at hand?
'abspath' does not deal with PATH-style directory lists, it accepts a
single file name as its argument.  What am I missing here?

>  In order to distinguish between these two i have added one more test to
> configure. It attempts to compile and run a small program which checks
> whether result of getcwd() is DOS-style. In case of cross-compiling it just
> knows that for DOS and MinGW native path style is DOS. Of course
> config.cache value is taken into account.
>  Technically it is possible to work around (2) using some clever heuristics,
> but i don't see how it would be possible to determine whether e.g. /foo/bar
> is an absolute path of DOS-style relative one.
>  Will this solution be OK ?

It probably would, if you do a clean job, but frankly I'm not sure
it's worth your while.  It is so easy to glean this information by
just looking at the appropriate preprocessor macro, like WINDOWS32
etc. that a configure-time test sounds like overkill.  But I won't
object to such a test, FWIW.

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

Re: [PATCH 2/2] Do not use DOS paths on Cygwin

[Eli Zaretskii]

> From: Pavel Fedin 
> Cc: m...@cgf.cx, bug-make@gnu.org
> Date: Tue, 06 Aug 2013 15:05:51 +0400
> 
> > In that case, we need to fix 'abspath', not disable this feature.
> 
>  Ok. If you don't mind, i can try new approach on this. Will it be OK ?

Yes, please.

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

RE: [PATCH 2/2] Do not use DOS paths on Cygwin

[Pavel Fedin]

 Hello!

> In that case, we need to fix 'abspath', not disable this feature.

 I have came up with another implementation, currently testing it.
 My new implementation should allow DOS and UNIX paths to coexist. However
there's still two differences:

1. abspath on Cygwin returns UNIX-style paths and on pure DOS/Windows -
DOS-style. If DOS-style absolute path is already supplied, it will leave it
as is.
2. PATH_SEPARATOR on Cygwin is ':' and on pure DOS/Windows is ';'.

 In order to distinguish between these two i have added one more test to
configure. It attempts to compile and run a small program which checks
whether result of getcwd() is DOS-style. In case of cross-compiling it just
knows that for DOS and MinGW native path style is DOS. Of course
config.cache value is taken into account.
 Technically it is possible to work around (2) using some clever heuristics,
but i don't see how it would be possible to determine whether e.g. /foo/bar
is an absolute path of DOS-style relative one.
 Will this solution be OK ?

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia



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

RE: [PATCH 2/2] Do not use DOS paths on Cygwin

[Pavel Fedin]

 Hello!

> In that case, we need to fix 'abspath', not disable this feature.

 Ok. If you don't mind, i can try new approach on this. Will it be OK ?

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia



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