msys2-runtime icon indicating copy to clipboard operation
msys2-runtime copied to clipboard

[meta] Reducing the diff to cygwin

Open lazka opened this issue 1 year ago • 5 comments

Here is a very small PR for starters: #218

Also related: https://github.com/msys2/msys2-runtime/issues/70

First, I think we should not try to hide "cygwin" from users, and just think of the msys2-runtime as differently configured cygwin. Otherwise reducing the difference wont really work.

While looking at the diff some questions came up:

  1. Should we rename things in comments as well?

There are multiple instances of this and while it's correct I'm wondering if that is worth it

diff --git a/winsup/utils/loadlib.h b/winsup/utils/loadlib.h
index c83b76478f..42ffbfdc03 100644
--- a/winsup/utils/loadlib.h
+++ b/winsup/utils/loadlib.h
@@ -13,7 +13,7 @@
 #include <wchar.h>
 
 /* Load all system libs from the windows system directory by prepending the
-   full path.  This doesn't work for loadling cygwin1.dll.  For this case,
+   full path.  This doesn't work for loadling msys-2.0.dll.  For this case,
    instead of prepending the path, make sure that the CWD is removed from
    the DLL search path, if possible (XP SP1++, Vista++). */
 static HMODULE _load_sys_library (const wchar_t *dll) __attribute__ ((used));
  1. Should our goal be to build the runtime under cygwin?

i.e. building under a cygwin env produces a msys2-runtime that can be copied and used to msys2.

If yes, we need to guard our changes with something different than __MSYS__ I think.

  1. Should our goal be that our fork also builds for cygwin if wanted?

i.e. disable all our changes via some configure flag to produce a cygwin runtime

If yes, we'd need to guard all our changes somehow. Potentially a lot work and increases the diff. Easier in C, harder in the build system.

lazka avatar Jul 09 '24 07:07 lazka

@dscho maybe you have some thoughts on the questions

lazka avatar Jul 09 '24 07:07 lazka

I guess the overall question is whether we would want to consider upstreaming all of MSYS2's changes. If we do, we could eventually even have a cygwin1.dll instead of an msys-2.0.dll and the entire difference is in the configuration (most likely /etc/nsswitch.conf).

If we don't want to go there, I think that we still want to rename the comments. Unless we are confident that we can avoid confusion when (admittedly, not very many) new contributors try to understand the source code.

As to the question whether we want to be able to build an MSYS2 runtime in Cygwin and vice versa, I am somewhat doubtful that that in and of itself would make for a valuable goal. What would be the benefit worth the effort?

dscho avatar Jul 09 '24 07:07 dscho

I guess the overall question is whether we would want to consider upstreaming all of MSYS2's changes. If we do, we could eventually even have a cygwin1.dll instead of an msys-2.0.dll and the entire difference is in the configuration (most likely /etc/nsswitch.conf).

It would be nice, but seems unrealistic at this point, i.e. it's not fun and there are more important things to do.

If we don't want to go there, I think that we still want to rename the comments. Unless we are confident that we can avoid confusion when (admittedly, not very many) new contributors try to understand the source code.

(it's not quite clear to me if you mean by rename, leave it renamed as is, or switch back to cygwin1.dll)

As to the question whether we want to be able to build an MSYS2 runtime in Cygwin and vice versa, I am somewhat doubtful that that in and of itself would make for a valuable goal. What would be the benefit worth the effort?

For "build the runtime under cygwin" would force things to be more upstreamable, and "our fork also builds for cygwin" would allow us to test things under cygwin to see if we broke unrelated functionality.

But yeah, probably not worth it.

lazka avatar Jul 09 '24 18:07 lazka

If we don't want to go there, I think that we still want to rename the comments. Unless we are confident that we can avoid confusion when (admittedly, not very many) new contributors try to understand the source code.

(it's not quite clear to me if you mean by rename, leave it renamed as is, or switch back to cygwin1.dll)

I meant that switching back to talking about cygwin1.dll in the comments even though we build msys-2.0.dll might be potentially very confusing.

dscho avatar Jul 09 '24 19:07 dscho

What would be the benefit worth the effort?

My personal favorite is https://www.msys2.org/wiki/Devtopics/#merge-with-cygwin "figure out if we can use Cygwin package repositories or if MSYS2 repositories can be used from Cygwin". Though it is a huge task, some little, seemingly insignificant steps may help to achieve that.

Biswa96 avatar Jul 09 '24 20:07 Biswa96