* Adding MSYS functionality to Cygwin
@ 2013-06-18 18:59 Алексей Павлов
2013-06-18 19:10 ` Christopher Faylor
` (3 more replies)
0 siblings, 4 replies; 51+ messages in thread
From: Алексей Павлов @ 2013-06-18 18:59 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-18 18:59 Adding MSYS functionality to Cygwin Алексей Павлов
@ 2013-06-18 19:10 ` Christopher Faylor
2013-06-18 19:30 ` Warren Young
` (2 subsequent siblings)
3 siblings, 0 replies; 51+ messages in thread
From: Christopher Faylor @ 2013-06-18 19:10 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-18 18:59 Adding MSYS functionality to Cygwin Алексей Павлов
2013-06-18 19:10 ` Christopher Faylor
@ 2013-06-18 19:30 ` Warren Young
2013-06-18 19:31 ` Алексей Павлов
2013-06-18 21:22 ` Adding MSYS functionality to Cygwin Christopher Faylor
2013-06-18 21:33 ` Charles Wilson
2013-06-19 15:56 ` Earnie Boyd
3 siblings, 2 replies; 51+ messages in thread
From: Warren Young @ 2013-06-18 19:30 UTC (permalink / raw)
To: Cygwin-L
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-18 19:30 ` Warren Young
@ 2013-06-18 19:31 ` Алексей Павлов
2013-06-18 22:12 ` Warren Young
2013-06-18 21:22 ` Adding MSYS functionality to Cygwin Christopher Faylor
1 sibling, 1 reply; 51+ messages in thread
From: Алексей Павлов @ 2013-06-18 19:31 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-18 19:30 ` Warren Young
2013-06-18 19:31 ` Алексей Павлов
@ 2013-06-18 21:22 ` Christopher Faylor
2013-06-18 21:29 ` Warren Young
1 sibling, 1 reply; 51+ messages in thread
From: Christopher Faylor @ 2013-06-18 21:22 UTC (permalink / raw)
To: cygwin
[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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-18 21:22 ` Adding MSYS functionality to Cygwin Christopher Faylor
@ 2013-06-18 21:29 ` Warren Young
2013-06-19 2:05 ` Christopher Faylor
0 siblings, 1 reply; 51+ messages in thread
From: Warren Young @ 2013-06-18 21:29 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-18 18:59 Adding MSYS functionality to Cygwin Алексей Павлов
2013-06-18 19:10 ` Christopher Faylor
2013-06-18 19:30 ` Warren Young
@ 2013-06-18 21:33 ` Charles Wilson
2013-06-19 2:06 ` Christopher Faylor
2013-06-19 15:56 ` Earnie Boyd
3 siblings, 1 reply; 51+ messages in thread
From: Charles Wilson @ 2013-06-18 21:33 UTC (permalink / raw)
To: The Cygwin Mailing List
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-18 19:31 ` Алексей Павлов
@ 2013-06-18 22:12 ` Warren Young
2013-06-18 22:35 ` Warren Young
` (3 more replies)
0 siblings, 4 replies; 51+ messages in thread
From: Warren Young @ 2013-06-18 22:12 UTC (permalink / raw)
To: Cygwin-L
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-18 22:12 ` Warren Young
@ 2013-06-18 22:35 ` Warren Young
2013-06-18 23:51 ` Warren Young
` (2 subsequent siblings)
3 siblings, 0 replies; 51+ messages in thread
From: Warren Young @ 2013-06-18 22:35 UTC (permalink / raw)
To: Cygwin-L
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-18 22:12 ` Warren Young
2013-06-18 22:35 ` Warren Young
@ 2013-06-18 23:51 ` Warren Young
2013-06-19 2:03 ` Christopher Faylor
2013-06-19 13:41 ` Charles Wilson
3 siblings, 0 replies; 51+ messages in thread
From: Warren Young @ 2013-06-18 23:51 UTC (permalink / raw)
To: Cygwin-L
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-18 22:12 ` Warren Young
2013-06-18 22:35 ` Warren Young
2013-06-18 23:51 ` Warren Young
@ 2013-06-19 2:03 ` Christopher Faylor
2013-06-19 7:17 ` Алексей Павлов
2013-06-19 17:31 ` Warren Young
2013-06-19 13:41 ` Charles Wilson
3 siblings, 2 replies; 51+ messages in thread
From: Christopher Faylor @ 2013-06-19 2:03 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-18 21:29 ` Warren Young
@ 2013-06-19 2:05 ` Christopher Faylor
2013-06-19 9:05 ` Corinna Vinschen
0 siblings, 1 reply; 51+ messages in thread
From: Christopher Faylor @ 2013-06-19 2:05 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-18 21:33 ` Charles Wilson
@ 2013-06-19 2:06 ` Christopher Faylor
2013-06-19 13:59 ` Charles Wilson
0 siblings, 1 reply; 51+ messages in thread
From: Christopher Faylor @ 2013-06-19 2:06 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-19 2:03 ` Christopher Faylor
@ 2013-06-19 7:17 ` Алексей Павлов
2013-06-19 8:15 ` Alexey Pavlov
2013-06-19 11:04 ` Corinna Vinschen
2013-06-19 17:31 ` Warren Young
1 sibling, 2 replies; 51+ messages in thread
From: Алексей Павлов @ 2013-06-19 7:17 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-19 7:17 ` Алексей Павлов
@ 2013-06-19 8:15 ` Alexey Pavlov
2013-06-19 11:04 ` Corinna Vinschen
1 sibling, 0 replies; 51+ messages in thread
From: Alexey Pavlov @ 2013-06-19 8:15 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-19 2:05 ` Christopher Faylor
@ 2013-06-19 9:05 ` Corinna Vinschen
2013-06-19 9:29 ` Corinna Vinschen
0 siblings, 1 reply; 51+ messages in thread
From: Corinna Vinschen @ 2013-06-19 9:05 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-19 9:05 ` Corinna Vinschen
@ 2013-06-19 9:29 ` Corinna Vinschen
2013-06-19 17:03 ` Warren Young
0 siblings, 1 reply; 51+ messages in thread
From: Corinna Vinschen @ 2013-06-19 9:29 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-19 7:17 ` Алексей Павлов
2013-06-19 8:15 ` Alexey Pavlov
@ 2013-06-19 11:04 ` Corinna Vinschen
2013-06-19 13:02 ` Alexey Pavlov
1 sibling, 1 reply; 51+ messages in thread
From: Corinna Vinschen @ 2013-06-19 11:04 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-19 11:04 ` Corinna Vinschen
@ 2013-06-19 13:02 ` Alexey Pavlov
0 siblings, 0 replies; 51+ messages in thread
From: Alexey Pavlov @ 2013-06-19 13:02 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-18 22:12 ` Warren Young
` (2 preceding siblings ...)
2013-06-19 2:03 ` Christopher Faylor
@ 2013-06-19 13:41 ` Charles Wilson
2013-06-19 18:38 ` Warren Young
3 siblings, 1 reply; 51+ messages in thread
From: Charles Wilson @ 2013-06-19 13:41 UTC (permalink / raw)
To: The Cygwin Mailing List
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-19 2:06 ` Christopher Faylor
@ 2013-06-19 13:59 ` Charles Wilson
0 siblings, 0 replies; 51+ messages in thread
From: Charles Wilson @ 2013-06-19 13:59 UTC (permalink / raw)
To: The Cygwin Mailing List
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-18 18:59 Adding MSYS functionality to Cygwin Алексей Павлов
` (2 preceding siblings ...)
2013-06-18 21:33 ` Charles Wilson
@ 2013-06-19 15:56 ` Earnie Boyd
2013-06-19 20:25 ` Corinna Vinschen
3 siblings, 1 reply; 51+ messages in thread
From: Earnie Boyd @ 2013-06-19 15:56 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-19 9:29 ` Corinna Vinschen
@ 2013-06-19 17:03 ` Warren Young
2013-06-19 17:36 ` Corinna Vinschen
0 siblings, 1 reply; 51+ messages in thread
From: Warren Young @ 2013-06-19 17:03 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-19 2:03 ` Christopher Faylor
2013-06-19 7:17 ` Алексей Павлов
@ 2013-06-19 17:31 ` Warren Young
2013-06-19 17:57 ` Christopher Faylor
1 sibling, 1 reply; 51+ messages in thread
From: Warren Young @ 2013-06-19 17:31 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-19 17:03 ` Warren Young
@ 2013-06-19 17:36 ` Corinna Vinschen
0 siblings, 0 replies; 51+ messages in thread
From: Corinna Vinschen @ 2013-06-19 17:36 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-19 17:31 ` Warren Young
@ 2013-06-19 17:57 ` Christopher Faylor
2013-06-20 3:30 ` Charles Wilson
0 siblings, 1 reply; 51+ messages in thread
From: Christopher Faylor @ 2013-06-19 17:57 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-19 13:41 ` Charles Wilson
@ 2013-06-19 18:38 ` Warren Young
2013-06-19 19:27 ` Yaakov (Cygwin/X)
0 siblings, 1 reply; 51+ messages in thread
From: Warren Young @ 2013-06-19 18:38 UTC (permalink / raw)
To: Cygwin-L
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-19 18:38 ` Warren Young
@ 2013-06-19 19:27 ` Yaakov (Cygwin/X)
2013-06-20 18:11 ` cygport limitations (was: Adding MSYS functionality to Cygwin) Warren Young
0 siblings, 1 reply; 51+ messages in thread
From: Yaakov (Cygwin/X) @ 2013-06-19 19:27 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-19 15:56 ` Earnie Boyd
@ 2013-06-19 20:25 ` Corinna Vinschen
0 siblings, 0 replies; 51+ messages in thread
From: Corinna Vinschen @ 2013-06-19 20:25 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-19 17:57 ` Christopher Faylor
@ 2013-06-20 3:30 ` Charles Wilson
2013-06-20 13:12 ` Earnie Boyd
0 siblings, 1 reply; 51+ messages in thread
From: Charles Wilson @ 2013-06-20 3:30 UTC (permalink / raw)
To: The Cygwin Mailing List
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-20 3:30 ` Charles Wilson
@ 2013-06-20 13:12 ` Earnie Boyd
2013-06-20 17:13 ` Corinna Vinschen
0 siblings, 1 reply; 51+ messages in thread
From: Earnie Boyd @ 2013-06-20 13:12 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Adding MSYS functionality to Cygwin
2013-06-20 13:12 ` Earnie Boyd
@ 2013-06-20 17:13 ` Corinna Vinschen
0 siblings, 0 replies; 51+ messages in thread
From: Corinna Vinschen @ 2013-06-20 17:13 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygport limitations (was: Adding MSYS functionality to Cygwin)
2013-06-19 19:27 ` Yaakov (Cygwin/X)
@ 2013-06-20 18:11 ` Warren Young
2013-06-20 18:44 ` Corinna Vinschen
` (2 more replies)
0 siblings, 3 replies; 51+ messages in thread
From: Warren Young @ 2013-06-20 18:11 UTC (permalink / raw)
To: Cygwin-L
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygport limitations (was: Adding MSYS functionality to Cygwin)
2013-06-20 18:11 ` cygport limitations (was: Adding MSYS functionality to Cygwin) Warren Young
@ 2013-06-20 18:44 ` Corinna Vinschen
2013-06-21 4:41 ` Andrew Schulman
2013-06-21 18:07 ` cygport limitations Warren Young
2013-06-20 19:11 ` Yaakov (Cygwin/X)
2013-06-20 22:31 ` David Stacey
2 siblings, 2 replies; 51+ messages in thread
From: Corinna Vinschen @ 2013-06-20 18:44 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygport limitations
2013-06-20 18:11 ` cygport limitations (was: Adding MSYS functionality to Cygwin) Warren Young
2013-06-20 18:44 ` Corinna Vinschen
@ 2013-06-20 19:11 ` Yaakov (Cygwin/X)
2013-06-21 7:26 ` Warren Young
2013-06-20 22:31 ` David Stacey
2 siblings, 1 reply; 51+ messages in thread
From: Yaakov (Cygwin/X) @ 2013-06-20 19:11 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygport limitations
2013-06-20 18:11 ` cygport limitations (was: Adding MSYS functionality to Cygwin) Warren Young
2013-06-20 18:44 ` Corinna Vinschen
2013-06-20 19:11 ` Yaakov (Cygwin/X)
@ 2013-06-20 22:31 ` David Stacey
2 siblings, 0 replies; 51+ messages in thread
From: David Stacey @ 2013-06-20 22:31 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygport limitations (was: Adding MSYS functionality to Cygwin)
2013-06-20 18:44 ` Corinna Vinschen
@ 2013-06-21 4:41 ` Andrew Schulman
2013-06-21 8:06 ` Corinna Vinschen
2013-06-21 18:07 ` cygport limitations Warren Young
1 sibling, 1 reply; 51+ messages in thread
From: Andrew Schulman @ 2013-06-21 4:41 UTC (permalink / raw)
To: cygwin
> 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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygport limitations
2013-06-20 19:11 ` Yaakov (Cygwin/X)
@ 2013-06-21 7:26 ` Warren Young
0 siblings, 0 replies; 51+ messages in thread
From: Warren Young @ 2013-06-21 7:26 UTC (permalink / raw)
To: Cygwin-L
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygport limitations (was: Adding MSYS functionality to Cygwin)
2013-06-21 4:41 ` Andrew Schulman
@ 2013-06-21 8:06 ` Corinna Vinschen
2013-06-21 16:55 ` Christopher Faylor
0 siblings, 1 reply; 51+ messages in thread
From: Corinna Vinschen @ 2013-06-21 8:06 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygport limitations (was: Adding MSYS functionality to Cygwin)
2013-06-21 8:06 ` Corinna Vinschen
@ 2013-06-21 16:55 ` Christopher Faylor
2013-06-21 20:35 ` Andrew Schulman
2013-06-24 9:13 ` Corinna Vinschen
0 siblings, 2 replies; 51+ messages in thread
From: Christopher Faylor @ 2013-06-21 16:55 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygport limitations
2013-06-20 18:44 ` Corinna Vinschen
2013-06-21 4:41 ` Andrew Schulman
@ 2013-06-21 18:07 ` Warren Young
2013-06-21 18:38 ` Warren Young
1 sibling, 1 reply; 51+ messages in thread
From: Warren Young @ 2013-06-21 18:07 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygport limitations
2013-06-21 18:07 ` cygport limitations Warren Young
@ 2013-06-21 18:38 ` Warren Young
2013-06-21 19:31 ` Yaakov (Cygwin/X)
0 siblings, 1 reply; 51+ messages in thread
From: Warren Young @ 2013-06-21 18:38 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygport limitations
2013-06-21 18:38 ` Warren Young
@ 2013-06-21 19:31 ` Yaakov (Cygwin/X)
2013-06-24 9:17 ` Corinna Vinschen
0 siblings, 1 reply; 51+ messages in thread
From: Yaakov (Cygwin/X) @ 2013-06-21 19:31 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygport limitations (was: Adding MSYS functionality to Cygwin)
2013-06-21 16:55 ` Christopher Faylor
@ 2013-06-21 20:35 ` Andrew Schulman
2013-06-21 21:01 ` Christopher Faylor
2013-06-24 9:13 ` Corinna Vinschen
1 sibling, 1 reply; 51+ messages in thread
From: Andrew Schulman @ 2013-06-21 20:35 UTC (permalink / raw)
To: cygwin
> 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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygport limitations (was: Adding MSYS functionality to Cygwin)
2013-06-21 20:35 ` Andrew Schulman
@ 2013-06-21 21:01 ` Christopher Faylor
0 siblings, 0 replies; 51+ messages in thread
From: Christopher Faylor @ 2013-06-21 21:01 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygport limitations (was: Adding MSYS functionality to Cygwin)
2013-06-21 16:55 ` Christopher Faylor
2013-06-21 20:35 ` Andrew Schulman
@ 2013-06-24 9:13 ` Corinna Vinschen
2013-06-24 11:31 ` Earnie Boyd
1 sibling, 1 reply; 51+ messages in thread
From: Corinna Vinschen @ 2013-06-24 9:13 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygport limitations
2013-06-21 19:31 ` Yaakov (Cygwin/X)
@ 2013-06-24 9:17 ` Corinna Vinschen
0 siblings, 0 replies; 51+ messages in thread
From: Corinna Vinschen @ 2013-06-24 9:17 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygport limitations (was: Adding MSYS functionality to Cygwin)
2013-06-24 9:13 ` Corinna Vinschen
@ 2013-06-24 11:31 ` Earnie Boyd
2013-06-24 11:56 ` Corinna Vinschen
0 siblings, 1 reply; 51+ messages in thread
From: Earnie Boyd @ 2013-06-24 11:31 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygport limitations (was: Adding MSYS functionality to Cygwin)
2013-06-24 11:31 ` Earnie Boyd
@ 2013-06-24 11:56 ` Corinna Vinschen
2013-06-25 11:12 ` Csaba Raduly
0 siblings, 1 reply; 51+ messages in thread
From: Corinna Vinschen @ 2013-06-24 11:56 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygport limitations (was: Adding MSYS functionality to Cygwin)
2013-06-24 11:56 ` Corinna Vinschen
@ 2013-06-25 11:12 ` Csaba Raduly
2013-06-25 12:06 ` Earnie Boyd
0 siblings, 1 reply; 51+ messages in thread
From: Csaba Raduly @ 2013-06-25 11:12 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygport limitations (was: Adding MSYS functionality to Cygwin)
2013-06-25 11:12 ` Csaba Raduly
@ 2013-06-25 12:06 ` Earnie Boyd
0 siblings, 0 replies; 51+ messages in thread
From: Earnie Boyd @ 2013-06-25 12:06 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 51+ messages in thread
end of thread, other threads:[~2013-06-25 11:12 UTC | newest]
Thread overview: 51+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-18 18:59 Adding MSYS functionality to Cygwin Алексей Павлов
2013-06-18 19:10 ` Christopher Faylor
2013-06-18 19:30 ` Warren Young
2013-06-18 19:31 ` Алексей Павлов
2013-06-18 22:12 ` Warren Young
2013-06-18 22:35 ` Warren Young
2013-06-18 23:51 ` Warren Young
2013-06-19 2:03 ` Christopher Faylor
2013-06-19 7:17 ` Алексей Павлов
2013-06-19 8:15 ` Alexey Pavlov
2013-06-19 11:04 ` Corinna Vinschen
2013-06-19 13:02 ` Alexey Pavlov
2013-06-19 17:31 ` Warren Young
2013-06-19 17:57 ` Christopher Faylor
2013-06-20 3:30 ` Charles Wilson
2013-06-20 13:12 ` Earnie Boyd
2013-06-20 17:13 ` Corinna Vinschen
2013-06-19 13:41 ` Charles Wilson
2013-06-19 18:38 ` Warren Young
2013-06-19 19:27 ` Yaakov (Cygwin/X)
2013-06-20 18:11 ` cygport limitations (was: Adding MSYS functionality to Cygwin) Warren Young
2013-06-20 18:44 ` Corinna Vinschen
2013-06-21 4:41 ` Andrew Schulman
2013-06-21 8:06 ` Corinna Vinschen
2013-06-21 16:55 ` Christopher Faylor
2013-06-21 20:35 ` Andrew Schulman
2013-06-21 21:01 ` Christopher Faylor
2013-06-24 9:13 ` Corinna Vinschen
2013-06-24 11:31 ` Earnie Boyd
2013-06-24 11:56 ` Corinna Vinschen
2013-06-25 11:12 ` Csaba Raduly
2013-06-25 12:06 ` Earnie Boyd
2013-06-21 18:07 ` cygport limitations Warren Young
2013-06-21 18:38 ` Warren Young
2013-06-21 19:31 ` Yaakov (Cygwin/X)
2013-06-24 9:17 ` Corinna Vinschen
2013-06-20 19:11 ` Yaakov (Cygwin/X)
2013-06-21 7:26 ` Warren Young
2013-06-20 22:31 ` David Stacey
2013-06-18 21:22 ` Adding MSYS functionality to Cygwin Christopher Faylor
2013-06-18 21:29 ` Warren Young
2013-06-19 2:05 ` Christopher Faylor
2013-06-19 9:05 ` Corinna Vinschen
2013-06-19 9:29 ` Corinna Vinschen
2013-06-19 17:03 ` Warren Young
2013-06-19 17:36 ` Corinna Vinschen
2013-06-18 21:33 ` Charles Wilson
2013-06-19 2:06 ` Christopher Faylor
2013-06-19 13:59 ` Charles Wilson
2013-06-19 15:56 ` Earnie Boyd
2013-06-19 20:25 ` Corinna Vinschen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).