Adding MSYS functionality to Cygwin

Adding MSYS functionality to Cygwin

[Алексей Павлов]

Hi everybody!

I want to add MSYS functionality to Cygwin.
More than 10 years ago Cygwin 1.3 had forked to MSYS. But now this
MSYS is very old and don't has any support for it.
Primary goal of MSYS is to provide environment with GNU utilities for
building application using native Mingw compilers. The main
differences from original Cygwin is working with native Win32
applications.
So I create new MSYS based on last Cygwin and it works good I think.
But I think that the right way is to implement MSYS functionality in
Cygwin sources directly because in this case we don't need to do many
copies of different Cygwin dll with other names. And we always has
latest work from Cygwin guys.

I can write next tasks that need to be in MSYS mode:

1. The correct definition of executables belonging to Cygwin DLL.
2. Translating paths in arguments and environment variables to Windows
form for pure Win32 applications.
3. In MSYS mode Cygwin need to be very portable: do not use registry
to store any info, do not use /etc/passwd and /etc/group, all mount
points need to be with noacl option to avoid problems with permission
denied.
4. Ability to change OSNAME that controlled by uname function in Cygwin DLL.
5. Use shorted mount point options in /etc/fstab - only win32_path and
posix_path.
6. SYMLINKS. Now Cygwin can work with native symlinks but it cannot be
used in all situations. From the other side - Win32 applications
doesn't understand Cygwin symlinks. As fallback option we need to
create copies of files and directories instead symlinks.

I want to hear your opinions about how it can be implemented in Cygwin codebase.

Regards,
Alexey.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Christopher Faylor]

On Tue, Jun 18, 2013 at 10:40:36PM +0400, ??????? ?????? wrote:
>Hi everybody!
>
>I want to add MSYS functionality to Cygwin.
>More than 10 years ago Cygwin 1.3 had forked to MSYS. But now this
>MSYS is very old and don't has any support for it.
>Primary goal of MSYS is to provide environment with GNU utilities for
>building application using native Mingw compilers. The main
>differences from original Cygwin is working with native Win32
>applications.
>So I create new MSYS based on last Cygwin and it works good I think.
>But I think that the right way is to implement MSYS functionality in
>Cygwin sources directly because in this case we don't need to do many
>copies of different Cygwin dll with other names. And we always has
>latest work from Cygwin guys.
>
>I can write next tasks that need to be in MSYS mode:
>
>1. The correct definition of executables belonging to Cygwin DLL.
>2. Translating paths in arguments and environment variables to Windows
>form for pure Win32 applications.
>3. In MSYS mode Cygwin need to be very portable: do not use registry
>to store any info, do not use /etc/passwd and /etc/group, all mount
>points need to be with noacl option to avoid problems with permission
>denied.
>4. Ability to change OSNAME that controlled by uname function in Cygwin DLL.
>5. Use shorted mount point options in /etc/fstab - only win32_path and
>posix_path.
>6. SYMLINKS. Now Cygwin can work with native symlinks but it cannot be
>used in all situations. From the other side - Win32 applications
>doesn't understand Cygwin symlinks. As fallback option we need to
>create copies of files and directories instead symlinks.
>
>I want to hear your opinions about how it can be implemented in Cygwin codebase.

Corinna and I have been discussing this in private and I thought
someone (you?) was going to bring this up in the cygwin-developers
list.

However, since you mention it here, my opinion is that we should add
hooks in the DLL which allow certain operations like path translation,
symlinks, and command line substitution to be short-circuited or
modified.  In that scenario, you'd still have a MSYS.dll but it would
rely on cygwin1.dll for most of the heavy lifting.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Warren Young]

On 6/18/2013 12:40, Алексей Павлов wrote:
>
> 1. The correct definition of executables belonging to Cygwin DLL.

Can you give an example of what you mean here?

This must be some kind of translation error, since executables never 
belong to DLLs.  The reverse is sometimes true, but mostly not.

> 2. Translating paths in arguments and environment variables to Windows
> form for pure Win32 applications.

I don't see how Cygwin can reliably predict when and whether to do this. 
  That is why it provides cygpath(1).  You, the user, use that tool when 
you know you need a translation done.

> 3. In MSYS mode Cygwin need to be very portable

It would indeed be nice to have a portable Cygwin.  That is, one that 
could be run from a copied directory or USB key, without being formally 
installed.  Such a thing would need to solve the 3PP problem, though, 
which is Hard (tm).

> 4. Ability to change OSNAME that controlled by uname function in Cygwin DLL.

Who needs this, and why?

> 5. Use shorted mount point options in /etc/fstab - only win32_path and
> posix_path.

Why do you need this?

Doesn't it conflict with your point #3?  A portable Cygwin would go out 
of its way to avoid using /etc/fstab.  I would guess that such a Cygwin 
variant would simply provide an unchangeable default behavior, and you'd 
have to be happy with it.

> 6. SYMLINKS. Now Cygwin can work with native symlinks but it cannot be
> used in all situations. From the other side - Win32 applications
> doesn't understand Cygwin symlinks. As fallback option we need to
> create copies of files and directories instead symlinks.

Copy semantics are not an acceptable fallback for ln.  (Or where they 
are, you can do your own copying.)

Example:

     $ ln -s dir1 dir2

Cygwin decides it can't make the symlink, so it spends a lot of I/O and 
disk space cloning the tree.  Bad enough.  But then:

      $ vi dir2/somefile.txt
      (make edits, :wq)

Now dir2/somefile.txt is not the same as dir1/somefile.txt.

This is going to break something, I'm sure of it.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Алексей Павлов]

2013/6/18 Warren Young <warren@etr-usa.com>:
> On 6/18/2013 12:40, Алексей Павлов wrote:
>>
>>
>> 1. The correct definition of executables belonging to Cygwin DLL.
>
>
> Can you give an example of what you mean here?
>
All cygwin applications depends on cygwin1.dll. We need to translate
arguments only for non-cygwin applications.

> This must be some kind of translation error, since executables never belong
> to DLLs.  The reverse is sometimes true, but mostly not.
>
>
>> 2. Translating paths in arguments and environment variables to Windows
>> form for pure Win32 applications.
>
>
> I don't see how Cygwin can reliably predict when and whether to do this.
> That is why it provides cygpath(1).  You, the user, use that tool when you
> know you need a translation done.
>
>
Win32 application doesn't know anything about cygwin paths and can't
use it. For example, you cannot do something like this on Cygwin:
 notepad /home/user/mydoc.txt
Also when you using autoconf utilities generated Makefile has Cygwin
paths and you cannot use it with native compiler.


>> 3. In MSYS mode Cygwin need to be very portable
>
>
> It would indeed be nice to have a portable Cygwin.  That is, one that could
> be run from a copied directory or USB key, without being formally installed.
> Such a thing would need to solve the 3PP problem, though, which is Hard
> (tm).
>
>
>> 4. Ability to change OSNAME that controlled by uname function in Cygwin
>> DLL.
>
>
> Who needs this, and why?
>
To use with native mingw compilers. We change OS to MINGW32 and
autoconf utilities think that it is Mingw shell.

>
>> 5. Use shorted mount point options in /etc/fstab - only win32_path and
>> posix_path.
>
>
> Why do you need this?
For backward compatibility with old MSYS and users experience of using MSYS.

>
> Doesn't it conflict with your point #3?  A portable Cygwin would go out of
> its way to avoid using /etc/fstab.  I would guess that such a Cygwin variant
> would simply provide an unchangeable default behavior, and you'd have to be
> happy with it.
>
No it doesn't conflict. Sometimes you need mount points. File
/etc/fstab doesn't break any portability option)

>
>> 6. SYMLINKS. Now Cygwin can work with native symlinks but it cannot be
>> used in all situations. From the other side - Win32 applications
>> doesn't understand Cygwin symlinks. As fallback option we need to
>> create copies of files and directories instead symlinks.
>
>
> Copy semantics are not an acceptable fallback for ln.  (Or where they are,
> you can do your own copying.)
>
> Example:
>
>     $ ln -s dir1 dir2
>
> Cygwin decides it can't make the symlink, so it spends a lot of I/O and disk
> space cloning the tree.  Bad enough.  But then:
>
>      $ vi dir2/somefile.txt
>      (make edits, :wq)
>
> Now dir2/somefile.txt is not the same as dir1/somefile.txt.
>
> This is going to break something, I'm sure of it.
>
For Win32 applications we cannot use Cygwin symlinks - only native.
But native symlinks sometimes can't be used - you haven't privileges
for it, filesystem doesn't support it.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Warren Young]

On 6/18/2013 13:30, ц║ц▄ц┘ц▀ц⌠ц┘ц┼ ц╟ц│ц≈ц▄ц▐ц≈ wrote:
> 2013/6/18 Warren Young <warren@etr-usa.com>:
>> On 6/18/2013 12:40, ц║ц▄ц┘ц▀ц⌠ц┘ц┼ ц╟ц│ц≈ц▄ц▐ц≈ wrote:
>>>
>>> 1. The correct definition of executables belonging to Cygwin DLL.
>>
>> Can you give an example of what you mean here?
>>
> All cygwin applications depends on cygwin1.dll. We need to translate
> arguments only for non-cygwin applications.

It would be possible, though somewhat evil, for Cygwin's exec() 
implementation to peek at the DLL dependency list of a program before 
starting it, and from that infer whether it should automatically 
translate paths.

The I/O hit this would cause would be nontrivial.  Keep in mind that one 
of the core ideas behind Unix is that fork() is cheap, and exec() is 
even cheaper.  This deeply affects how software native to Unixy systems 
gets designed.  As a result, Cygwin already has a problem with its slow 
fork() implementation; this idea makes exec() expensive, too, with 
predictable consequences to overall system speed.

I don't see how Cygwin couldn't afford to behave this way by default. 
Maybe as an option?

>>> 2. Translating paths in arguments and environment variables to Windows

I just re-read this, and realized the implications of "and environment 
variables."  You're proposing some kind of global search-and-replace 
operation, which will inevitably turn into a Whac-a-Mole game.

(http://goo.gl/vpYfA)

>   notepad /home/user/mydoc.txt

 From my explanation above, you do see how expensive it would be for 
Cygwin to implement your desired behavior, right?

> Also when you using autoconf utilities generated Makefile has Cygwin
> paths and you cannot use it with native compiler.

Those on the Automake list have wrestled with this off and on.  It's 
more or less impossible to solve, which is why competing systems like 
CMake, SCons and Bakefile were created.

I think the best you can hope for is that if you run ./configure under 
Cygwin with CC=i686-pc-mingw32-gcc and such, it creates a Makefile that 
works with Cygwin make, which calls out to the MinGW cross-compiler. 
Since the cross-compiler is a Cygwin app, not a native executable, it 
understands POSIX paths yet still builds native Windows executables.

Or, you could say "./configure CC=mingw32-gcc" and depend on my proposed 
answer to your point #1.

>>> 4. Ability to change OSNAME that controlled by uname function in Cygwin
>>> DLL.
>>
>>
>> Who needs this, and why?
>>
> To use with native mingw compilers. We change OS to MINGW32 and
> autoconf utilities think that it is Mingw shell.

What's wrong with using the MinGW cross-compiler from the Cygwin package 
repository instead?

>>> 5. Use shorted mount point options in /etc/fstab - only win32_path and
>>> posix_path.
>>
>>
>> Why do you need this?
> For backward compatibility with old MSYS and users experience of using MSYS.

I don't see why that's Cygwin's concern.

It should be sufficient for Cygwin to provides a reasonable path 
forward, so that those relying on MSYS can migrate to the new scheme.

Infinite backwards compatibility is its own problem.

>> Doesn't it conflict with your point #3?  A portable Cygwin would go out of
>> its way to avoid using /etc/fstab.  I would guess that such a Cygwin variant
>> would simply provide an unchangeable default behavior, and you'd have to be
>> happy with it.
>>
> No it doesn't conflict. Sometimes you need mount points. File
> /etc/fstab doesn't break any portability option)

If you need custom mount points and such, use Cygwin.

> For Win32 applications we cannot use Cygwin symlinks - only native.
> But native symlinks sometimes can't be used - you haven't privileges
> for it, filesystem doesn't support it.

I already know that.  Your proposal is wrong-headed from the start.  If 
you repeat it, it's still incorrect.

Here's something for you to try on your own system:

     $ cd /bin
     $ mv ln.exe sane-ln.exe
     $ ln -s cp.exe ln.exe

Or if you're feeling really ambitious, do it at the cygwin1.dll level, 
by changing its implementations of link(2) and symlink(2) to recursive 
copy operations.  You have the source.

If the resulting system works well at all, it will be much slower.  I 
predict you'll find that something breaks, though, due to the semantic 
issues I tried to show by example in my previous post.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Warren Young]

On 6/18/2013 16:04, Warren Young wrote:
>      $ cd /bin
>      $ mv ln.exe sane-ln.exe
>      $ ln -s cp.exe ln.exe

Of course, that final step should be

     $ cp cp.exe ln.exe

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Warren Young]

On 6/18/2013 16:04, Warren Young wrote:
> You're proposing some kind of global search-and-replace
> operation, which will inevitably turn into a Whac-a-Mole game.

I just thought of an example.  How many POSIX paths are in this 
perfectly legal command, which invokes a native Windows executable?

     $ xcopy /bin foo bar

The wrong answer is, "three."

Now tell me how cygwin1.dll is expected to realize it should only 
translate the final two arguments to xcopy.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Christopher Faylor]

On Tue, Jun 18, 2013 at 04:04:06PM -0600, Warren Young wrote:
>On 6/18/2013 13:30, ??????? ?????? wrote:
>> 2013/6/18 Warren Young <warren@etr-usa.com>:
>>> On 6/18/2013 12:40, ??????? ?????? wrote:
>>>>
>>>> 1. The correct definition of executables belonging to Cygwin DLL.
>>>
>>> Can you give an example of what you mean here?
>>>
>> All cygwin applications depends on cygwin1.dll. We need to translate
>> arguments only for non-cygwin applications.
>
>It would be possible, though somewhat evil, for Cygwin's exec() 
>implementation to peek at the DLL dependency list of a program before 
>starting it, and from that infer whether it should automatically 
>translate paths.

Cygwin already does this.  It detects whether the program it is about
to run uses the Cygwin DLL and, if not, makes decisions on how to
handle exec.  It would be relatively easy to extend this.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Алексей Павлов]

2013/6/19 Christopher Faylor wrote:
> On Tue, Jun 18, 2013 at 04:04:06PM -0600, Warren Young wrote:
>>On 6/18/2013 13:30, ??????? ?????? wrote:
>>> 2013/6/18 Warren Young :
>>>> On 6/18/2013 12:40, ??????? ?????? wrote:
>>>>>
>>>>> 1. The correct definition of executables belonging to Cygwin DLL.
>>>>
>>>> Can you give an example of what you mean here?
>>>>
>>> All cygwin applications depends on cygwin1.dll. We need to translate
>>> arguments only for non-cygwin applications.
>>
>>It would be possible, though somewhat evil, for Cygwin's exec()
>>implementation to peek at the DLL dependency list of a program before
>>starting it, and from that infer whether it should automatically
>>translate paths.
>
> Cygwin already does this.  It detects whether the program it is about
> to run uses the Cygwin DLL and, if not, makes decisions on how to
> handle exec.  It would be relatively easy to extend this.
>

Thanks for the point Christopher.
Today I investigate in this direction and find that logic works well
except one line in spawn.cc that I think can be fixed without break
anything.

Index: cygwin/spawn.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/spawn.cc,v
retrieving revision 1.345
diff -u -p -r1.345 spawn.cc
--- cygwin/spawn.cc 3 May 2013 19:39:01 -0000 1.345
+++ cygwin/spawn.cc 19 Jun 2013 05:53:36 -0000
@@ -406,7 +406,7 @@ child_info_spawn::worker (const char *pr
}
else
{
- if (wascygexec)
+ if (real_path.iscygexec ())
newargv.dup_all ();
else if (!one_line.fromargv (newargv, real_path.get_win32 (),
real_path.iscygexec ()))


Regards,
Alexey.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Alexey Pavlov]

I want point all who read this ML to mingw-w64 ML discussion about MSYS:
http://sourceforge.net/mailarchive/message.php?msg_id=31008339

Also I want to say that all changes that I do in Cygwin DLL (except
symlink-copy) do not break any Cygwin stuff and only applied to
non-cygwin applications. For Cygwin applications doesn't changed
anything.

1. OSNAME
By default is Cygwin, but if you want - you can change it.

2. Paths translating - only for Win32 applications.

3. Symlink-to-copy I think can be implementing for stupid or crazy
(what you want) guys as me by something like
CYGWIN=symlinks:wincompat.

Regards,
Alexey.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Corinna Vinschen]

On Jun 19 10:53, Алексей Павлов wrote:
> Today I investigate in this direction and find that logic works well
> except one line in spawn.cc that I think can be fixed without break
> anything.
> 
> Index: cygwin/spawn.cc
> ===================================================================
> RCS file: /cvs/src/src/winsup/cygwin/spawn.cc,v
> retrieving revision 1.345
> diff -u -p -r1.345 spawn.cc
> --- cygwin/spawn.cc 3 May 2013 19:39:01 -0000 1.345
> +++ cygwin/spawn.cc 19 Jun 2013 05:53:36 -0000
> @@ -406,7 +406,7 @@ child_info_spawn::worker (const char *pr
> }
> else
> {
> - if (wascygexec)
> + if (real_path.iscygexec ())

Line 374:

  wascygexec = real_path.iscygexec ();

Do you have an example why your change should make a difference?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Alexey Pavlov]

2013/6/19 Corinna Vinschen :
> On Jun 19 10:53, Алексей Павлов wrote:
>> Today I investigate in this direction and find that logic works well
>> except one line in spawn.cc that I think can be fixed without break
>> anything.
>>
>> Index: cygwin/spawn.cc
>> ===================================================================
>> RCS file: /cvs/src/src/winsup/cygwin/spawn.cc,v
>> retrieving revision 1.345
>> diff -u -p -r1.345 spawn.cc
>> --- cygwin/spawn.cc 3 May 2013 19:39:01 -0000 1.345
>> +++ cygwin/spawn.cc 19 Jun 2013 05:53:36 -0000
>> @@ -406,7 +406,7 @@ child_info_spawn::worker (const char *pr
>> }
>> else
>> {
>> - if (wascygexec)
>> + if (real_path.iscygexec ())
>
> Line 374:
>
>   wascygexec = real_path.iscygexec ();
>
> Do you have an example why your change should make a difference?
>
My opinion is next:
wascygexec is initialized before calling av::fixup that determine is
executable depends on Cygwin1.dll and always (for me) is 0. But in
av::fixup real_path.iscygexec () can be changed.
And code always go to condition with one_line.fromargv.

Regards, Alexey.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Warren Young]

On 6/18/2013 20:02, Christopher Faylor wrote:
> On Tue, Jun 18, 2013 at 04:04:06PM -0600, Warren Young wrote:
>> It would be possible, though somewhat evil, for Cygwin's exec()
>> implementation to peek at the DLL dependency list of a program before
>> starting it, and from that infer whether it should automatically
>> translate paths.
>
> Cygwin already does this.  It detects whether the program it is about
> to run uses the Cygwin DLL and, if not, makes decisions on how to
> handle exec.  It would be relatively easy to extend this.

Well, given that we're already paying the "peek" cost, I don't have any 
objection to making exec() take longer for the native Windows case only.

Do you know how you want to cope with my contrived "xcopy /bin a b" 
example?  The point of the example, of course, is that "/bin" looks like 
a real, existing POSIX path, but isn't.

 From Chuck's explanation of MSYS, looks like "/b /i /n" would also get 
caught in their heuristics, since it apparently doesn't do file 
existence checks.  (Else, Chuck's dumpbin example wouldn't need a 
workaround.)

File existence checks would fix that, but would then prevent this from 
doing what you want:

     $ notepad ~/tmp/newfile.txt

So, it looks like MSYS is right not to try file existence checks.

(Yes, I realize you can rewrite my xcopy example using dashes for the 
flags.  That's beside the broader point, which is that not all things 
that look like POSIX paths are such.)

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Christopher Faylor]

On Wed, Jun 19, 2013 at 11:30:11AM -0600, Warren Young wrote:
>On 6/18/2013 20:02, Christopher Faylor wrote:
>> On Tue, Jun 18, 2013 at 04:04:06PM -0600, Warren Young wrote:
>>> It would be possible, though somewhat evil, for Cygwin's exec()
>>> implementation to peek at the DLL dependency list of a program before
>>> starting it, and from that infer whether it should automatically
>>> translate paths.
>>
>> Cygwin already does this.  It detects whether the program it is about
>> to run uses the Cygwin DLL and, if not, makes decisions on how to
>> handle exec.  It would be relatively easy to extend this.
>
>Well, given that we're already paying the "peek" cost, I don't have any 
>objection to making exec() take longer for the native Windows case only.
>
>Do you know how you want to cope with my contrived "xcopy /bin a b" 
>example?  The point of the example, of course, is that "/bin" looks like 
>a real, existing POSIX path, but isn't.

I don't think people are getting this:

*How this is implemented doesn't matter*.

I'm talking about providing hooks so that an add-on MSYS dll could
modify the windows command-line.  Then we wouldn't care what MSYS does
with the command-line since it isn't a Cygwin DLL decision.  The goal is
to allow a small DLL to hook into Cygwin and do whatever MSYS wants to
do.

Something like:

callout (CO_EXEC, &command_line);

Where it is expected that the command line could be modified.

The "check-for-windows" code is already there.  Calling out would be
close to a no-op in the non-MSYS cost.  Otherwise, I really don't care
what it costs.

I understand the objections to the way that MSYS does things.  I really
do.  I don't like what it does, either (and I've voiced the same
objections in the past) but we're willing to selectively modify Cygwin
to allow it to be used as the engine that drives future MSYS
development.  The goal would be to collapse the fork back into Cygwin
with minimal cost to the Cygwin DLL.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Charles Wilson]

On 6/19/2013 1:45 PM, Christopher Faylor wrote:
> I'm talking about providing hooks so that an add-on MSYS dll could
> modify the windows command-line.  Then we wouldn't care what MSYS does
> with the command-line since it isn't a Cygwin DLL decision.  The goal is
> to allow a small DLL to hook into Cygwin and do whatever MSYS wants to
> do.
>
> Something like:
>
> callout (CO_EXEC, &command_line);
>
> Where it is expected that the command line could be modified.

Interesting. Obviously, there's more to a "complete" MSYS 
replacement/reimplementation, but cmd-line manipulation for exec'ing 
native apps is really the biggest MSYS-ism of the bunch.

I assume that, eventually and as-needed, a *small* number of additional 
"hooks" could be added to other code paths than exec/spawn/etc -- such 
as the aforementioned uname(3) thing. (One of the "deltas" between 
cygwin and msys was msys used a really stupid ownership/permission model 
-- pretend current user owns everything; check the DOS R/O bit for +w; 
check the file extension for +x; -- but this can be approximated with 
existing $CYGWIN entries or mount options. I think. So reimplementing 
that "feature" of MSYS would not require any additional hooks).

> The goal would be to collapse the fork back into Cygwin
> with minimal cost to the Cygwin DLL.

+1 <g>

--
Chuck



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Earnie Boyd]

On Wed, Jun 19, 2013 at 4:25 PM, Charles Wilson wrote:
>
> I assume that, eventually and as-needed, a *small* number of additional
> "hooks" could be added to other code paths than exec/spawn/etc -- such as
> the aforementioned uname(3) thing. (One of the "deltas" between cygwin and
> msys was msys used a really stupid ownership/permission model -- pretend
> current user owns everything; check the DOS R/O bit for +w; check the file
> extension for +x; -- but this can be approximated with existing $CYGWIN
> entries or mount options. I think. So reimplementing that "feature" of MSYS
> would not require any additional hooks).

IIRC that "stupid ownership/permission model" was a part of the
original Cygwin 1.3 and was not modified.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Corinna Vinschen]

On Jun 20 09:07, Earnie Boyd wrote:
> On Wed, Jun 19, 2013 at 4:25 PM, Charles Wilson wrote:
> >
> > I assume that, eventually and as-needed, a *small* number of additional
> > "hooks" could be added to other code paths than exec/spawn/etc -- such as
> > the aforementioned uname(3) thing. (One of the "deltas" between cygwin and
> > msys was msys used a really stupid ownership/permission model -- pretend
> > current user owns everything; check the DOS R/O bit for +w; check the file
> > extension for +x; -- but this can be approximated with existing $CYGWIN
> > entries or mount options. I think. So reimplementing that "feature" of MSYS
> > would not require any additional hooks).
> 
> IIRC that "stupid ownership/permission model" was a part of the
> original Cygwin 1.3 and was not modified.

CYGWIN=ntsec ruled way back when...


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Charles Wilson]

On 6/18/2013 6:04 PM, Warren Young wrote:
> It would be possible, though somewhat evil, for Cygwin's exec()
> implementation to peek at the DLL dependency list of a program before
> starting it, and from that infer whether it should automatically
> translate paths.
>
> The I/O hit this would cause would be nontrivial.  Keep in mind that one
> of the core ideas behind Unix is that fork() is cheap, and exec() is
> even cheaper.  This deeply affects how software native to Unixy systems
> gets designed.  As a result, Cygwin already has a problem with its slow
> fork() implementation; this idea makes exec() expensive, too, with
> predictable consequences to overall system speed.
>
> I don't see how Cygwin couldn't afford to behave this way by default.
> Maybe as an option?

This is what MSYS-1 does. If the executable depends on the msys dll, 
then no path translation is done. If the executable does NOT depend on 
the msys dll, then path translation heuristics are employed. The speed 
hit of this check is relatively insignificant, all things considered. 
The biggest bugaboo is that "heuristic" == "a guess that is sometimes 
wrong".  MSYS handles things like scanning argv[] for stuff like 
-I/unixy/path and -L/unixy/path (also, I think, --some-opt=/unixy/path), 
in addition to standalong args that look like paths.

That stuff is slow...and often erroneous (e.g. in "dumpbin.exe 
/symbols", '/symbols' is an option, not a path...)  So there are 
workarounds:

bash-3.1$ dumpbin /symbols
Microsoft (R) COFF/PE Dumper Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file C:/MinGW/msys/1.0/symbols
LINK : fatal error LNK1181: cannot open input file 
'C:/MinGW/msys/1.0/symbols'

Using multiple leading '/' disables path translation (*):
bash-3.1$ dumpbin //symbols
Microsoft (R) COFF/PE Dumper Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.


   Summary

(*) except that there are ADDITIONAL heuristics to determine if the 
argument is actually a UNC path, which SHOULD start with 2 / !!
http://www.mingw.org/wiki/Posix_path_conversion

This is not a simple task.

>>>> 2. Translating paths in arguments and environment variables to Windows
>
> I just re-read this, and realized the implications of "and environment
> variables."  You're proposing some kind of global search-and-replace
> operation, which will inevitably turn into a Whac-a-Mole game.
>
> (http://goo.gl/vpYfA)

Yes, yes it is. Welcome to MSYS.

>>   notepad /home/user/mydoc.txt
>
>  From my explanation above, you do see how expensive it would be for
> Cygwin to implement your desired behavior, right?
>
>> Also when you using autoconf utilities generated Makefile has Cygwin
>> paths and you cannot use it with native compiler.

> Those on the Automake list have wrestled with this off and on.  It's
> more or less impossible to solve, which is why competing systems like
> CMake, SCons and Bakefile were created.

And why msys's make.exe exists. It understands the "cygwin" paths in the 
Makefile, but when it launches (the native win32 "mingw" compiler) 
gcc.exe via the MSYS fork()/exec() codepath, all of the above heuristics 
come into play and (win32)gcc.exe gets all the wonderful X:/dos/style 
paths it likes.  OR so goes the idea.

> I think the best you can hope for is that if you run ./configure under
> Cygwin with CC=i686-pc-mingw32-gcc and such, it creates a Makefile that
> works with Cygwin make, which calls out to the MinGW cross-compiler.
> Since the cross-compiler is a Cygwin app, not a native executable, it
> understands POSIX paths yet still builds native Windows executables.
>
> Or, you could say "./configure CC=mingw32-gcc" and depend on my proposed
> answer to your point #1.
>
>>>> 4. Ability to change OSNAME that controlled by uname function in Cygwin
>>>> DLL.

> What's wrong with using the MinGW cross-compiler from the Cygwin package
> repository instead?

Not all packages are cross-compiler-compatible. Arguably and ideally, 
THAT is what should be fixed, but we don't live in an ideal world.

> Here's something for you to try on your own system:
>
>      $ cd /bin
>      $ mv ln.exe sane-ln.exe
>      $ ln -s cp.exe ln.exe
>
> Or if you're feeling really ambitious, do it at the cygwin1.dll level,
> by changing its implementations of link(2) and symlink(2) to recursive
> copy operations.  You have the source.

This is what MSYS-1 does.

> If the resulting system works well at all, it will be much slower.

It is.

--
Chuck




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Warren Young]

On 6/19/2013 07:31, Charles Wilson wrote:
>
> http://www.mingw.org/wiki/Posix_path_conversion

That's good info.

I'm glad to see that relative paths are never molested.  I tried for a 
while to confuse Cygwin and native Windows programs using relative 
paths, and failed to find a case where the path doesn't mean the same 
thing to both sides.

> Not all packages are cross-compiler-compatible.

Is that another way of saying that not all packages use autotools? :)

You're not talking about anything different than the sort of thing 
Cygwin package maintainers go through, sometimes needing to arm-twist 
odd build systems to behave according to cygport's expectations?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Yaakov (Cygwin/X)]

On 2013-06-19 12:57, Warren Young wrote:
>> Not all packages are cross-compiler-compatible.
>
> Is that another way of saying that not all packages use autotools? :)

autotools can certainly make cross-compiling easier than most other 
build systems, but it's not a guarantee either.  For instance, anything 
that requires in-tree compiled executables to run (e.g. AC_RUN_IFELSE 
configure tests, GObject Introspection generation, etc.) requires either 
workarounds, or simply cannot be cross-compiled.

> You're not talking about anything different than the sort of thing
> Cygwin package maintainers go through, sometimes needing to arm-twist
> odd build systems to behave according to cygport's expectations?

I think you mean Cygwin's expectations?


Yaakov


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygport limitations (was: Adding MSYS functionality to Cygwin)

[Warren Young]

On 6/19/2013 12:38, Yaakov (Cygwin/X) wrote:
> On 2013-06-19 12:57, Warren Young wrote:
>> You're not talking about anything different than the sort of thing
>> Cygwin package maintainers go through, sometimes needing to arm-twist
>> odd build systems to behave according to cygport's expectations?
>
> I think you mean Cygwin's expectations?

Not really, no.

I'm assuming everyone is using cygport now to create packages, or can't 
because of one of these violated expectations.

My ctags package is one of the latter, because although it ships with a 
configure script, it isn't an autoconf configure script.  When I tried 
migrating the package to cygport 3.5 years ago, cygport failed to DTRT 
because the ctags build system doesn't know how to configure and build 
outside the source tree.  I ended up falling back on my custom build 
script, which simply builds in-tree, then overrides some make(!) 
variables to force it to install into a temp directory, which I then 
pack up by hand.  This is tolerable because ctags is a relatively simple 
package.

I think I see how to get cygport to build this package now, but it 
wouldn't buy me much, because I'd be overriding so much of its default 
behavior.  All I'd be doing is pushing it into this next category.

That second category of packages are those that are built using cygport 
despite the fact that it requires a highly customized .cygport file. 
The more customizations you add, the more of cygport's base assumptions 
you are violating with your package.

The last doxygen package I shipped was a good example of this:

1. I had to pass "--platform linux-g++" to configure to get it to build 
correctly.  (It might have been one of those cases where it saw #if 
WINDOWS == true and did the wrong thing.)  I don't know if CYGCONF_ARGS 
didn't exist when I wrote that, but for some reason I felt compelled to 
override the src_compile rule to pass this flag.

2. Though I now know about CYGCONF_ARGS, if I picked the package back up 
for some reason, I don't think I could get rid of my src_compile() 
override because of a second build problem: Doxygen's own documentation 
has a primitive and completely separate build system.  Not only does 
"make" at the top level not "cd doc && make", but doc/Makefile also 
doesn't understand things like DESTDIR.  I ended up needing to override 
src_install(), too.

I don't mean to impugn cygport's capabilities, or yours, Yaakov.  I 
prefer to use cygport, and don't like it when I can't.

My point is, cygport's default assumptions about how software gets built 
and installed aren't always correct.  Sometimes it has enough 
flexibility to cope with those differences (e.g. my doxygen case) and 
other times it's just not worth the bother (e.g. my ctags case).

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygport limitations (was: Adding MSYS functionality to Cygwin)

[Corinna Vinschen]

On Jun 20 11:43, Warren Young wrote:
> On 6/19/2013 12:38, Yaakov (Cygwin/X) wrote:
> >On 2013-06-19 12:57, Warren Young wrote:
> >>You're not talking about anything different than the sort of thing
> >>Cygwin package maintainers go through, sometimes needing to arm-twist
> >>odd build systems to behave according to cygport's expectations?
> >
> >I think you mean Cygwin's expectations?
> 
> Not really, no.
> [...]
> My point is, cygport's default assumptions about how software gets
> built and installed aren't always correct.  Sometimes it has enough
> flexibility to cope with those differences (e.g. my doxygen case)
> and other times it's just not worth the bother (e.g. my ctags case).

My point is, it's always worth to switch packages to cygport:

- cygport is the closest we have to a unified build system (like rpm).
  If every maintainer would use cygport, it would allow us to change
  the build method to one along the lines of most Linux distros.
  In Linux distros, the maintainer provides only the spec file and
  the source archive.  The actual build for all supported platforms 
  could be done on a machine which creates the distro from there.

- Cygport does cope with most problems you can come up with and if
  it doesn't, you can tweak it.  Your ctags problem could have been
  easily solved by the lndirs method, for instance.  And if cygport
  still doesn't cope, there's an active maintainer and a cygwin-apps
  mailing list for questions.

- Cygport is pretty easy to use and other people can easily pick up
  your package and build another version using your Cygwin build
  settings, or even take over maintainership should the need arise.

Of course, the better is the foe of the good, but unless somebody comes
up with another build system which integrates nicely into Cygwin and is
easier to use than cygport, cygport is the best system we have and I
advocate for using it throughout.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygport limitations (was: Adding MSYS functionality to Cygwin)

[Andrew Schulman]

>   If every maintainer would use cygport, it would allow us to change
>   the build method to one along the lines of most Linux distros.
>   In Linux distros, the maintainer provides only the spec file and
>   the source archive.  The actual build for all supported platforms 
>   could be done on a machine which creates the distro from there.

That would be cool.  Let's do it!


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygport limitations (was: Adding MSYS functionality to Cygwin)

[Corinna Vinschen]

On Jun 20 22:38, Andrew Schulman wrote:
> >   If every maintainer would use cygport, it would allow us to change
> >   the build method to one along the lines of most Linux distros.
> >   In Linux distros, the maintainer provides only the spec file and
> >   the source archive.  The actual build for all supported platforms 
> >   could be done on a machine which creates the distro from there.
> 
> That would be cool.  Let's do it!

Uhm, that was a projection into the ideal future.  No provisions have
been made yet.  We need to set up a central repository like Yaakov's
cygwinports git repo and a central build mechanism.  The first we can
probably shamelessly copy from Yaakov and set up over the next few
months, the second needs a bit of hacking.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygport limitations (was: Adding MSYS functionality to Cygwin)

[Christopher Faylor]

On Fri, Jun 21, 2013 at 09:49:34AM +0200, Corinna Vinschen wrote:
>On Jun 20 22:38, Andrew Schulman wrote:
>> >   If every maintainer would use cygport, it would allow us to change
>> >   the build method to one along the lines of most Linux distros.
>> >   In Linux distros, the maintainer provides only the spec file and
>> >   the source archive.  The actual build for all supported platforms 
>> >   could be done on a machine which creates the distro from there.
>> 
>> That would be cool.  Let's do it!
>
>Uhm, that was a projection into the ideal future.  No provisions have
>been made yet.  We need to set up a central repository like Yaakov's
>cygwinports git repo and a central build mechanism.  The first we can
>probably shamelessly copy from Yaakov and set up over the next few
>months, the second needs a bit of hacking.

I'm not sure if this reminder is needed but, I'm not switching to
cygport and I believe there are also a couple of other people using
non-cygport packagers as well.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygport limitations (was: Adding MSYS functionality to Cygwin)

[Andrew Schulman]

> On Fri, Jun 21, 2013 at 09:49:34AM +0200, Corinna Vinschen wrote:
> >On Jun 20 22:38, Andrew Schulman wrote:
> >> >   If every maintainer would use cygport, it would allow us to change
> >> >   the build method to one along the lines of most Linux distros.
> >> >   In Linux distros, the maintainer provides only the spec file and
> >> >   the source archive.  The actual build for all supported platforms 
> >> >   could be done on a machine which creates the distro from there.
> >> 
> >> That would be cool.  Let's do it!
> >
> >Uhm, that was a projection into the ideal future.  No provisions have
> >been made yet.  We need to set up a central repository like Yaakov's
> >cygwinports git repo and a central build mechanism.  The first we can
> >probably shamelessly copy from Yaakov and set up over the next few
> >months, the second needs a bit of hacking.
> 
> I'm not sure if this reminder is needed but, I'm not switching to
> cygport and I believe there are also a couple of other people using
> non-cygport packagers as well.

I guess there will always be some maintainers who don't want to use
cygport, but I don't think that should be a reason to keep all of the rest
of us from moving from the current labor-intensive manual build process, to
a more labor-efficient automated process.  

This vision seems like the future to me.  More people will maintain more
packages if they can spend less of their time babysitting manual build and
upload processes.  The distro maintainers should ultimately see a decrease
in their labor too.

For packages that don't work well with cygport, maybe it would be
worthwhile to still support the current manual upload method.  The number
of those packages would apparently be small.  But if a maintainer just
doesn't want to use cygport, then I think we should ask whether the project
should spend its resources accomodating that preference.

I understand that the project doesn't seem ready to take on this task yet,
but when there's a need for development or system administration effort to
make that vision happen, I'd like to help.

Andrew


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygport limitations (was: Adding MSYS functionality to Cygwin)

[Christopher Faylor]

On Fri, Jun 21, 2013 at 04:03:46PM -0400, Andrew Schulman wrote:
>>On Fri, Jun 21, 2013 at 09:49:34AM +0200, Corinna Vinschen wrote:
>>>On Jun 20 22:38, Andrew Schulman wrote:
>>>>>If every maintainer would use cygport, it would allow us to change the
>>>>>build method to one along the lines of most Linux distros.  In Linux
>>>>>distros, the maintainer provides only the spec file and the source
>>>>>archive.  The actual build for all supported platforms could be done on
>>>>>a machine which creates the distro from there.
>>>>
>>>>That would be cool.  Let's do it!
>>>
>>>Uhm, that was a projection into the ideal future.  No provisions have
>>>been made yet.  We need to set up a central repository like Yaakov's
>>>cygwinports git repo and a central build mechanism.  The first we can
>>>probably shamelessly copy from Yaakov and set up over the next few
>>>months, the second needs a bit of hacking.
>>
>>I'm not sure if this reminder is needed but, I'm not switching to
>>cygport and I believe there are also a couple of other people using
>>non-cygport packagers as well.
>
>I guess there will always be some maintainers who don't want to use
>cygport, but I don't think that should be a reason to keep all of the
>rest of us from moving from the current labor-intensive manual build
>process, to a more labor-efficient automated process.

You've introduced a false dilemma.  There is no reason to assume that
any build system will be so limited as to be able to only run one type
of build mechanism.  The one that I use could easily be dropped into
any automated build.

Also, while I'm happy to help set up some kind of central repository,
please don't anyone assume that sourceware will be used to build
packages.  That is not an appropriate use of the system.  So, someone
(Red Hat?) would have to offer up a system to build everything.

I've said repeatedly that I'd like to fix the current upload mechanism
that we use for Cygwin.  I've tried a couple of different mechanisms but
neither was really good enough.

>For packages that don't work well with cygport, maybe it would be
>worthwhile to still support the current manual upload method.  The
>number of those packages would apparently be small.  But if a
>maintainer just doesn't want to use cygport, then I think we should ask
>whether the project should spend its resources accomodating that
>preference.

I don't see any reason to adopt that harsh a stance but again: false
dilemma...

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygport limitations (was: Adding MSYS functionality to Cygwin)

[Corinna Vinschen]

On Jun 21 10:34, Christopher Faylor wrote:
> On Fri, Jun 21, 2013 at 09:49:34AM +0200, Corinna Vinschen wrote:
> >On Jun 20 22:38, Andrew Schulman wrote:
> >> >   If every maintainer would use cygport, it would allow us to change
> >> >   the build method to one along the lines of most Linux distros.
> >> >   In Linux distros, the maintainer provides only the spec file and
> >> >   the source archive.  The actual build for all supported platforms 
> >> >   could be done on a machine which creates the distro from there.
> >> 
> >> That would be cool.  Let's do it!
> >
> >Uhm, that was a projection into the ideal future.  No provisions have
> >been made yet.  We need to set up a central repository like Yaakov's
> >cygwinports git repo and a central build mechanism.  The first we can
> >probably shamelessly copy from Yaakov and set up over the next few
> >months, the second needs a bit of hacking.
> 
> I'm not sure if this reminder is needed but, I'm not switching to
> cygport

Pity.

> and I believe there are also a couple of other people using
> non-cygport packagers as well.

Using another build system doesn't mean you can't switch to the better
one.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygport limitations (was: Adding MSYS functionality to Cygwin)

[Earnie Boyd]

On Mon, Jun 24, 2013 at 5:11 AM, Corinna Vinschen wrote:
>
> Using another build system doesn't mean you can't switch to the better
> one.

That depends on one's view of better and Chris already believes he
uses the better one.  That is why is refuses to use something else.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygport limitations (was: Adding MSYS functionality to Cygwin)

[Corinna Vinschen]

On Jun 24 07:03, Earnie Boyd wrote:
> On Mon, Jun 24, 2013 at 5:11 AM, Corinna Vinschen wrote:
> >
> > Using another build system doesn't mean you can't switch to the better
> > one.
> 
> That depends on one's view of better and Chris already believes he
> uses the better one.  That is why is refuses to use something else.

man teasing.  Apparently I forgot the ;)


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygport limitations (was: Adding MSYS functionality to Cygwin)

[Csaba Raduly]

On Mon, Jun 24, 2013 at 1:55 PM, Corinna Vinschen  wrote:
> On Jun 24 07:03, Earnie Boyd wrote:
>> On Mon, Jun 24, 2013 at 5:11 AM, Corinna Vinschen wrote:
>> >
>> > Using another build system doesn't mean you can't switch to the better
>> > one.
>>
>> That depends on one's view of better and Chris already believes he
>> uses the better one.  That is why is refuses to use something else.
>
> man teasing.  Apparently I forgot the ;)

$ man teasing
No manual entry for teasing

(: Csaba :)
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygport limitations (was: Adding MSYS functionality to Cygwin)

[Earnie Boyd]

On Tue, Jun 25, 2013 at 5:02 AM, Csaba Raduly wrote:
> On Mon, Jun 24, 2013 at 1:55 PM, Corinna Vinschen  wrote:
>> On Jun 24 07:03, Earnie Boyd wrote:
>>> On Mon, Jun 24, 2013 at 5:11 AM, Corinna Vinschen wrote:
>>> >
>>> > Using another build system doesn't mean you can't switch to the better
>>> > one.
>>>
>>> That depends on one's view of better and Chris already believes he
>>> uses the better one.  That is why is refuses to use something else.
>>
>> man teasing.  Apparently I forgot the ;)
>
> $ man teasing
> No manual entry for teasing

I should have thought of that one yesterday. ;p

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygport limitations

[Warren Young]

On 6/20/2013 12:10, Corinna Vinschen wrote:
>    If every maintainer would use cygport, it would allow us to change
>    the build method to one along the lines of most Linux distros.
>    In Linux distros, the maintainer provides only the spec file and
>    the source archive.  The actual build for all supported platforms
>    could be done on a machine which creates the distro from there.

With cygport, you wouldn't even need to provide sources.  We could email 
in the new cygport file instead of an RFU.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygport limitations

[Warren Young]

On 6/21/2013 12:05, Warren Young wrote:
> On 6/20/2013 12:10, Corinna Vinschen wrote:
>>    If every maintainer would use cygport, it would allow us to change
>>    the build method to one along the lines of most Linux distros.
>>    In Linux distros, the maintainer provides only the spec file and
>>    the source archive.  The actual build for all supported platforms
>>    could be done on a machine which creates the distro from there.
>
> With cygport, you wouldn't even need to provide sources.  We could email
> in the new cygport file instead of an RFU.

...and patches.

...and customized .hint files, if needed.

Yeah, I guess sending the .src.tar.bz2 probably is effectively required.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygport limitations

[Yaakov (Cygwin/X)]

On 2013-06-21 13:10, Warren Young wrote:
> On 6/21/2013 12:05, Warren Young wrote:
>> With cygport, you wouldn't even need to provide sources.  We could email
>> in the new cygport file instead of an RFU.
>
> ...and patches.
>
> ...and customized .hint files, if needed.
>
> Yeah, I guess sending the .src.tar.bz2 probably is effectively required.

No, it's not.  IIUC, the eventual goal should be something that looks 
like Ports git:

http://cygwin-ports.git.sourceforge.net/

together with a buildbot.  Package maintainers would then commit their 
changes to a package's repo, which would then trigger a post-commit hook 
that would cause the package to be built with those changes.


Yaakov


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygport limitations

[Corinna Vinschen]

On Jun 21 13:50, Yaakov (Cygwin/X) wrote:
> On 2013-06-21 13:10, Warren Young wrote:
> >On 6/21/2013 12:05, Warren Young wrote:
> >>With cygport, you wouldn't even need to provide sources.  We could email
> >>in the new cygport file instead of an RFU.
> >
> >...and patches.
> >
> >...and customized .hint files, if needed.
> >
> >Yeah, I guess sending the .src.tar.bz2 probably is effectively required.
> 
> No, it's not.  IIUC, the eventual goal should be something that
> looks like Ports git:
> 
> http://cygwin-ports.git.sourceforge.net/
> 
> together with a buildbot.  Package maintainers would then commit
> their changes to a package's repo, which would then trigger a
> post-commit hook that would cause the package to be built with those
> changes.

Yes, that sounds good.  The last discussions in my dept about setting up
a build system are long gone, so we have to start anew.  This will take
some time (think unsavory things like budgets and so on...), but I'll
keep on it.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygport limitations

[Yaakov (Cygwin/X)]

On 2013-06-20 12:43, Warren Young wrote:
> I'm assuming everyone is using cygport now to create packages, or can't
> because of one of these violated expectations.
>
> My ctags package is one of the latter, because although it ships with a
> configure script, it isn't an autoconf configure script.  When I tried
> migrating the package to cygport 3.5 years ago, cygport failed to DTRT
> because the ctags build system doesn't know how to configure and build
> outside the source tree.  I ended up falling back on my custom build
> script, which simply builds in-tree, then overrides some make(!)
> variables to force it to install into a temp directory, which I then
> pack up by hand.  This is tolerable because ctags is a relatively simple
> package.

This is explained in the manual wrt cygconf:

> * cygconf is intended for configure scripts generated by, or compatible
>   with, autoconf. Packages with handwritten configure scripts may not
>   accept allthe flags used by cygconf, in which case a direct call to
>   the configure  script is in order.

In this case, not having looked at ctags, you'll probably need something 
along the lines of:

src_compile() {
     lndirs
     cd ${B}
     ./configure --prefix=/usr || error "configure failed"
     cygmake
}

> That second category of packages are those that are built using cygport
> despite the fact that it requires a highly customized .cygport file. The
> more customizations you add, the more of cygport's base assumptions you
> are violating with your package.
>
> The last doxygen package I shipped was a good example of this:
>
> 1. I had to pass "--platform linux-g++" to configure to get it to build
> correctly.  (It might have been one of those cases where it saw #if
> WINDOWS == true and did the wrong thing.)  I don't know if CYGCONF_ARGS
> didn't exist when I wrote that, but for some reason I felt compelled to
> override the src_compile rule to pass this flag.

FWIW, CYGCONF_ARGS has been around for a *long* time.

> 2. Though I now know about CYGCONF_ARGS, if I picked the package back up
> for some reason, I don't think I could get rid of my src_compile()
> override because of a second build problem: Doxygen's own documentation
> has a primitive and completely separate build system.  Not only does
> "make" at the top level not "cd doc && make", but doc/Makefile also
> doesn't understand things like DESTDIR.  I ended up needing to override
> src_install(), too.

There's nothing wrong with that.  src_compile(), src_test(), and 
src_install() are intended to be provided by cygport(5)s; the provided 
*defaults* of those are NOT opaque APIs (hence they are actually shown 
in the docs) and are meant to be overridden whenever necessary.

> I don't mean to impugn cygport's capabilities, or yours, Yaakov.  I
> prefer to use cygport, and don't like it when I can't.

There should NEVER be a reason that you can't use cygport for your 
packages.  If you're having an issue, just provide your (draft) 
cygport(5) and ask.


Yaakov


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygport limitations

[Warren Young]

On 6/20/2013 12:44, Yaakov (Cygwin/X) wrote:
>
> There should NEVER be a reason that you can't use cygport for your
> packages.  If you're having an issue, just provide your (draft)
> cygport(5) and ask.

Thanks for the offer.  I've left myself a note to try this again for the 
next ctags release.

I have no idea if there ever will be a new Exuberant Ctags.  The last 
release came out 4 years ago, and activity to the ctags-devel list has 
been under 1 post per month[*] for the past 6 months.

I'd be willing to convert 5.8 to cygport if this plan of Corinna's for 
an automated build server goes through.

[*] http://sourceforge.net/mailarchive/forum.php?forum_name=ctags-devel

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygport limitations

[David Stacey]

On 20/06/13 18:43, Warren Young wrote:
> The last doxygen package I shipped was a good example of this:
>
> 1. I had to pass "--platform linux-g++" to configure to get it to 
> build correctly.  (It might have been one of those cases where it saw 
> #if WINDOWS == true and did the wrong thing.)  I don't know if 
> CYGCONF_ARGS didn't exist when I wrote that, but for some reason I 
> felt compelled to override the src_compile rule to pass this flag.
>
> 2. Though I now know about CYGCONF_ARGS, if I picked the package back 
> up for some reason, I don't think I could get rid of my src_compile() 
> override because of a second build problem: Doxygen's own 
> documentation has a primitive and completely separate build system.  
> Not only does "make" at the top level not "cd doc && make", but 
> doc/Makefile also doesn't understand things like DESTDIR.  I ended up 
> needing to override src_install(), too.

In defence of cygport, it does a great job of subscribing to the Alan 
Kay principle: simple things are simple, and hard things are possible. 
If you think about just how many software packages there are in the 
Linux world, there are also a great many different techniques for 
building them. Cygport is really easy for most modern packages that 
adhere to (or are fairly close to) a "standard" install, and at least 
the packages that have, ahem, specialist installation mechanisms can be 
built with cygport too.

The other great thing about cygport is that it has become the standard 
for building Cygwin packages, so all (or at least most of) the Cygwin 
maintainers can read and understand cygport files. This means it's much 
easier when the time comes to hand a package on to a new maintainer.

Maybe this is straying into the "[RFC] cygport documentation" thread 
from the apps ML, but perhaps we could do with a cygport gallery: a 
selection of cygport files ranging from the deliciously simple three or 
four line affairs through to the more stubborn and difficult cases. I 
know that I've picked up some handy techniques by looking at other 
maintainers' cygport files.

Dave.

PS: As the current doxygen maintainer, I am sad to report that the 
cygport file isn't any smaller now that I'm building doxywizard, doing a 
test for libclang-devel (so that I can enable or disable clang assisted 
parsing), and forcing it to make a debuginfo package :-)


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Christopher Faylor]

[I'm being a reluctant explicator here]

On Tue, Jun 18, 2013 at 01:10:06PM -0600, Warren Young wrote:
>On 6/18/2013 12:40, ?????????????? ???????????? wrote:
>>
>> 1. The correct definition of executables belonging to Cygwin DLL.
>
>Can you give an example of what you mean here?
>
>This must be some kind of translation error, since executables never 
>belong to DLLs.  The reverse is sometimes true, but mostly not.

I don't get this one either.  Maybe the OP means that cygwin has to know
when to translate command-line arguments for non-Cygwin executables?

>> 2. Translating paths in arguments and environment variables to Windows
>> form for pure Win32 applications.
>
>I don't see how Cygwin can reliably predict when and whether to do this. 
>  That is why it provides cygpath(1).  You, the user, use that tool when 
>you know you need a translation done.

Yep.  Welcome to MSYS.  I believe that MSYS translates "things that look
like paths" so if you do something like: "foo /blah/blurf" and "foo" is
a Windows program then "/blah/blurf" gets translated into
"c:\whatever\blah\blurf".

>> 3. In MSYS mode Cygwin need to be very portable
>
>It would indeed be nice to have a portable Cygwin.  That is, one that 
>could be run from a copied directory or USB key, without being formally 
>installed.  Such a thing would need to solve the 3PP problem, though, 
>which is Hard (tm).

Why wouldn't that work now?  You can copy cygwin1.dll anywhere you want.

>> 4. Ability to change OSNAME that controlled by uname function in Cygwin DLL.
>
>Who needs this, and why?

Maybe it needs to identify itself as "MSYS" for configure scripts?

>> 5. Use shorted mount point options in /etc/fstab - only win32_path and
>> posix_path.
>
>Why do you need this?
>
>Doesn't it conflict with your point #3?  A portable Cygwin would go out 
>of its way to avoid using /etc/fstab.  I would guess that such a Cygwin 
>variant would simply provide an unchangeable default behavior, and you'd 
>have to be happy with it.

Don't get this one either.

>> 6. SYMLINKS. Now Cygwin can work with native symlinks but it cannot be
>> used in all situations. From the other side - Win32 applications
>> doesn't understand Cygwin symlinks. As fallback option we need to
>> create copies of files and directories instead symlinks.
>
>Copy semantics are not an acceptable fallback for ln.  (Or where they 
>are, you can do your own copying.)

All of the above is just an explanation of the way that MSYS currently
operates.  The argument about semantics of ln (which I agree with)
doesn't really matter since "that's how MSYS works".

This is, however, one of the reasons why I'm not comfortable modifying
Cygwin to behave differently.  Having spent the last 15 years telling
people "That isn't the way POSIX works" makes it hard for me to say
"But if that's what you want then just set CYGWIN=WINCOMPAT and you'll
get it" .

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Warren Young]

On 6/18/2013 13:31, Christopher Faylor wrote:
> On Tue, Jun 18, 2013 at 01:10:06PM -0600, Warren Young wrote:
>>> 3. In MSYS mode Cygwin need to be very portable
>>
>> It would indeed be nice to have a portable Cygwin.  That is, one that
>> could be run from a copied directory or USB key, without being formally
>> installed.  Such a thing would need to solve the 3PP problem, though,
>> which is Hard (tm).
>
> Why wouldn't that work now?  You can copy cygwin1.dll anywhere you want.

Because FAQ item 4.19, and because 3PP.

I'm envisioning some configuration option (runtime or build time) that 
would create a cygwin1.dll that only serves the executable(s) shipped 
alongside it.  If there is more than one executable, they would only be 
expected to cooperate with each other, so that the need for a common 
cygheap wouldn't obtain.

Such a distribution wouldn't be "Cygwin" per se.  Its primary purpose 
would be so people could bundle the DLL with a program that runs in its 
own little world, or a system of such programs.

In this mode, Cygwin wouldn't require any persistent configuration 
(files on disk, the registry, etc.) or create such.  It would start up 
in its default mode, provide whatever services the executable that 
loaded it required, and quietly go away again without leaving any 
footprints behind when unloaded.

The executable linked to cygwin1p.dll ('p' = portable build variant) 
could make any persistent changes it wanted, of course.  I'm just saying 
that this Portable Cygwin DLL that I have handwaved into existence 
shouldn't do this on its own behalf, or require that anyone else do it 
for the DLL ahead of time.

In other words, I'm trying to turn the second 'P' in 3PP back into 
"Packagers".  Bring the perverts back into the fold, as it were, instead 
of casting them out, thus giving them no reason to try and cooperate 
with mainline Cygwin.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Christopher Faylor]

On Tue, Jun 18, 2013 at 03:24:52PM -0600, Warren Young wrote:
>On 6/18/2013 13:31, Christopher Faylor wrote:
>> On Tue, Jun 18, 2013 at 01:10:06PM -0600, Warren Young wrote:
>>>> 3. In MSYS mode Cygwin need to be very portable
>>>
>>> It would indeed be nice to have a portable Cygwin.  That is, one that
>>> could be run from a copied directory or USB key, without being formally
>>> installed.  Such a thing would need to solve the 3PP problem, though,
>>> which is Hard (tm).
>>
>> Why wouldn't that work now?  You can copy cygwin1.dll anywhere you want.
>
>Because FAQ item 4.19, and because 3PP.

The FAQ is out-of-date.  Multiple Cygwin copies should coexist peacefully
these days although it still is something that we wouldn't necessarily
advocate for a novice user.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Corinna Vinschen]

On Jun 18 22:03, Christopher Faylor wrote:
> On Tue, Jun 18, 2013 at 03:24:52PM -0600, Warren Young wrote:
> >On 6/18/2013 13:31, Christopher Faylor wrote:
> >> On Tue, Jun 18, 2013 at 01:10:06PM -0600, Warren Young wrote:
> >>>> 3. In MSYS mode Cygwin need to be very portable
> >>>
> >>> It would indeed be nice to have a portable Cygwin.  That is, one that
> >>> could be run from a copied directory or USB key, without being formally
> >>> installed.  Such a thing would need to solve the 3PP problem, though,
> >>> which is Hard (tm).
> >>
> >> Why wouldn't that work now?  You can copy cygwin1.dll anywhere you want.
> >
> >Because FAQ item 4.19, and because 3PP.
> 
> The FAQ is out-of-date.  Multiple Cygwin copies should coexist peacefully
> these days although it still is something that we wouldn't necessarily
> advocate for a novice user.

I'll rewrite that FAQ.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Corinna Vinschen]

On Jun 19 10:15, Corinna Vinschen wrote:
> On Jun 18 22:03, Christopher Faylor wrote:
> > On Tue, Jun 18, 2013 at 03:24:52PM -0600, Warren Young wrote:
> > >On 6/18/2013 13:31, Christopher Faylor wrote:
> > >> On Tue, Jun 18, 2013 at 01:10:06PM -0600, Warren Young wrote:
> > >>>> 3. In MSYS mode Cygwin need to be very portable
> > >>>
> > >>> It would indeed be nice to have a portable Cygwin.  That is, one that
> > >>> could be run from a copied directory or USB key, without being formally
> > >>> installed.  Such a thing would need to solve the 3PP problem, though,
> > >>> which is Hard (tm).
> > >>
> > >> Why wouldn't that work now?  You can copy cygwin1.dll anywhere you want.
> > >
> > >Because FAQ item 4.19, and because 3PP.
> > 
> > The FAQ is out-of-date.  Multiple Cygwin copies should coexist peacefully
> > these days although it still is something that we wouldn't necessarily
> > advocate for a novice user.
> 
> I'll rewrite that FAQ.

Done.  Please have a look:
http://cygwin.com/faq.html#faq.using.multiple-copies
http://cygwin.com/faq.html#faq.using.third-party.multiple-copies


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Warren Young]

On 6/19/2013 03:05, Corinna Vinschen wrote:
>
> Done.  Please have a look:
> http://cygwin.com/faq.html#faq.using.multiple-copies
> http://cygwin.com/faq.html#faq.using.third-party.multiple-copies

Thanks!

It looks like 4.22 is still out of date, though.  The "must be run 
serially" bit, at least, conflicts with the new explanation in 4.19.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Corinna Vinschen]

On Jun 19 10:53, Warren Young wrote:
> On 6/19/2013 03:05, Corinna Vinschen wrote:
> >
> >Done.  Please have a look:
> >http://cygwin.com/faq.html#faq.using.multiple-copies
> >http://cygwin.com/faq.html#faq.using.third-party.multiple-copies
> 
> Thanks!
> 
> It looks like 4.22 is still out of date, though.  The "must be run
> serially" bit, at least, conflicts with the new explanation in 4.19.

Thanks for checking.  I dropped the 4.22 FAQ entry completely.  It just
doesn't make sense anymore.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Charles Wilson]

On 6/18/2013 2:40 PM, Алексей Павлов wrote:
> I want to add MSYS functionality to Cygwin.
> More than 10 years ago Cygwin 1.3 had forked to MSYS. But now this
> MSYS is very old and don't has any support for it.
...
>
> I want to hear your opinions about how it can be implemented in Cygwin codebase.

Go over to the mingw.org mailing lists; there is ongoing effort related 
to MSYS2 which is based on a much more recent fork of cygwin IIUC. Also, 
many of the earlier hacks that msys-1 implemented are no longer needed 
thanks to exploiting new features in the underlying cygwin (like: 
/etc/fstab).

Also, I *think* the development is being tracked as a branch from a 
cygwin repo clone, so keeping msys2 updated with respect to cygwin 
changes should be easier.

However, discussing "not-cygwin" on the cygwin list(s) is A Bad Idea, so 
you should go "over there" and talk it out with those guys.

--
Chuck


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Christopher Faylor]

On Tue, Jun 18, 2013 at 05:29:04PM -0400, Charles Wilson wrote:
>However, discussing "not-cygwin" on the cygwin list(s) is A Bad Idea, so 
>you should go "over there" and talk it out with those guys.

Let me state it again: Corinna and I have been having private discussion
about this and are open to talking about the possibility of adding
MSYS capability to Cygwin.  I'm advocating adding hooks to the DLL
which would accomplish that.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Charles Wilson]

On 6/18/2013 10:05 PM, Christopher Faylor wrote:
> Let me state it again: Corinna and I have been having private discussion
> about this and are open to talking about the possibility of adding
> MSYS capability to Cygwin.  I'm advocating adding hooks to the DLL
> which would accomplish that.

Wow, that's VERY interesting.  Thanks for clarifying your stance.

--
Chuck

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Earnie Boyd]

On Tue, Jun 18, 2013 at 2:40 PM, Алексей Павлов wrote:
> I want to add MSYS functionality to Cygwin.

One issue with that would be copyright assignment.  Alexey has been in
the MSYS code so someone who hasn't looked would need to implement
similar functionality.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Adding MSYS functionality to Cygwin

[Corinna Vinschen]

On Jun 19 11:04, Earnie Boyd wrote:
> On Tue, Jun 18, 2013 at 2:40 PM, Алексей Павлов wrote:
> > I want to add MSYS functionality to Cygwin.
> 
> One issue with that would be copyright assignment.  Alexey has been in
> the MSYS code so someone who hasn't looked would need to implement
> similar functionality.

Only if it becomes part of Cygwin.  If we implement the plugin/hook
method, the licensing is no problem.  The plugin could certainly
use plain GPLv3+ again.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple