* 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: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-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 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-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: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 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: 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 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: 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 (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 (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 (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 (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
* 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 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 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 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 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: 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 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-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 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 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-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 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: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 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
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).