joe: Joe's own editor

[dlmiles]

My first MSYS2 package contribution.

[dlmiles]

Just to report I have been using this for over a month and works just like native Linux console / xterm / SSH.

It is a tried and tested text editor that has been around longer than most with low maintenance overhead over the years.

Does the PKGBUILD file need a formal reviewed to promote it to having generally available status ? It is not clear what the process is at this point.

There is not necessarily any rush I am just confirming there isn't an action from me that is being waited on in this process.

Once I have understood the process and I can then work on the next one (PKGBUILD for another package) to enhance an existing MSYS2 package with the availability of a performance improvement library.

[dlmiles]

Tried the github sync button. Not sure why it doesn't work out there is zero conflict to fast-forward and rebase on top. All fixed now. No wonder github projects are in a mess.

This is a force-push is a rebase on top of current master.

What is the limiting factor with progress on with this ?

Thanks

[lazka]

What is the limiting factor with progress on with this ?

We are trying to keep the number of msys packages low, mainly to what we need to for development and packaging of mingw packages.

Depending on the type of package, the reason why it is needed, the complexity of the packaging/dependencies we might consider adding new packages.

Just curious, why do you need this package?

[dlmiles]

It is a text editor that has been around for 30 years, doesn't require much maintenance per decade and is feature complete. I looked to see where other text-mode text editors (with few dependencies) were positioned in the MSYS2 package space and found them in this project repository.

Maybe the project FAQ instructions on msys2 website for 'contributing your first package' should have a process to establish which repository should be used.

It is possible to setup the builder for this project to target another package space. It is not clear to me at this time what package space that would be. Do I just replicate and test it for all the combinations that exist ?

This project is not expected to be (or become) a dependency for another project.

I do have a library libjudy (C library API, no external dependencies) which has not been submitted to the process yet (as I am using this package joe as a process learning exercise). libjudy is expected to be a dependency for another (existing) project in the mingw-w64-x86_64 space. It is not clear if libjudy should be submitted here or over there.

It would certainly be useful to have some boilerplate message added to this PR concerning this matter at an earlier time, it is has not been clear until now who is waiting for what, if processes have been followed, what considerations need to occur, where this specific PR is in the processes that exist, as none of this is in the 'contributing your first package' section of the msys2 website.

[sskras]

@dlmiles commented 9 hours ago:

Maybe the project FAQ instructions on msys2 website for 'contributing your first package' should have a process to establish which repository should be used.

I agree, saying that in the FAQ might help.

Actually there are instructions about creating a new package, and these refers to the MINGW repository / space by offering the example / starting point: https://www.msys2.org/dev/new-package/

It is not clear to me at this time what package space that would be. Do I just replicate and test it for all the combinations that exist ?

I got hit by that too. Every time I was considering to use MSYS2 in the past.

It would be a lot more easier for a user if the FAQ or even the front page would contain link to this page or maybe a similar intro: https://www.msys2.org/wiki/How-does-MSYS2-differ-from-Cygwin/

To be short (even if subjective):

• MSYS2 exists to make building MINGW applications easier.
• MINGW is an open source alternative to MSVC
  (even if based on *nix-like shell and GCC).
• This enables building native Win32 (Win64) apps.
• There is no place to add POSIX-based apps here.
• The exception is POSIX-based apps that are tools required for porting the app to Windows.
  (eg. Bash, Libtool)

I guess joe isn't a build-dep for any of *nix-like apps. And so it should belong to the MINGW (native Windows) world, not to the MSYS2 (the emulated POSIX).

The problem might be that joe hasn't been ported to Windows (WinAPI or msvcrt/ucrt). So to put it into MINGW repo might require significant rewriting / porting effort from you (esp. in the terminal I/O handling department).

I am *nix-guy working on Windows, and this dichotomy sometimes makes me mad at MSYS2. While package management on MSYS2 makes me happy. Combined these polarizing effects puts quite a strain on me.

At the moment, I see only two easy (or at least additional) ways to solve that:

1. you start hosting your own Pacman repository with the MSYS2 builds of your software.
2. you start using some other system where POSIX-based apps are the first class citizens.

I know only of two active projects that goes the latter way:

• Cygwin
  (especially now that MSYS2 is going to become its' plugin instead of being a separate fork)
• Midipix
  (pre-alpha, this summer it's expected to get its' first release, so it just might not fit you)

Speaking of Cygwin, it seems to have this package already:
https://cygwin.com/packages/summary/joe.html

This project is not expected to be (or become) a dependency for another project.

I guess, being a no dep makes the project even less needed for software building.
Although one might argue that the porter can only work with the given editor. :)

I do have a library libjudy (C library API, no external dependencies) [...]. libjudy is expected to be a dependency for another (existing) project in the mingw-w64-x86_64 space. It is not clear if libjudy should be submitted here or over there.

IMO this clearly says to put it into MINGW repo. Especially when it supports building with MSVC.

Just my €.02

[dlmiles]

Thanks for your comments.

Windows has been POSIX for a long time. Maybe the early days of CYGWIN had to implement emulation wrappers as implementation disagreements between Unix variants used to exist in early days. Coverage and compatibility is pretty good today surely ?

joe package is largely built on top of ncurses for the heaving lifting (although it looks to link statically, using the DLL is something I can improve in this PKGBUILD). There maybe some ioctl and termios work, that is outside of ncurses APIs but you might find they are optional, due to use of autoconf by joe.

ncurses is available in MSYS2 and MINGW64.

I have been a CYGWIN user for a long time in the past, but not recently, as WSL2 came around.

The version of joe (built from the PKGBUILD in this PR) inside msys2 terminal, the ldd and ntldd report only msys-2.0.dll being required for linkage. Are you saying all the symbols linked with this need to be migrated ?

Using objdump -t joe.exe indicate 143 entries. If I remove the estimated 80% of C standard library, C99 symbols for libm and libc symbol (which are neither POSIX or Windows native APIs) the areas left can be broadly said to be. signal handling, termios, fork/pipe/kill, getpwnam, fcntl, ioctl.
Would it be correct to infer from your information, these APIs need to be disabled (I think autoconf will help in a number of areas) or ported to Windows native APIs based on MSVCRT ?

I notice nano also exists in the installation I have for MSYS2 UCRT (this package repo) and it links to msys-2.0.dll.

Re the hosting a pacman repo, I shall explore the avenue for GHA built and hosting of a pacman repo. Then provide copy-and-paste instructions in a toplevel README.md file to add the repo and install.

So my plan:

1. Fix PKGBUILD to link with DLL for ncurses (and anything else that is also DLL, like nano does), the hope here is those 143 symbols will reduce as they are not needed directly by joe.exe code, so no work to port needed by me.
2. Modify default autoconf settings to disable things that are just not necessary on Windows. Or add new #ifdef to remove unwanted features not worth porting (getpwnam stuff, some direct ioctl, some fcntl)
3. Examine what symbols remain in the linkage to msys-2.0.dll from joe.exe.
4. Get the result autobuilding on my own GHA infrastructure and publish gh-pages.
5. Look at the possibility to copy-and-paste someone elses work from another MINGW OSS project with compatible license that has already solved the same areas left worth porting (Ctrl-C signal handling).

[lazka]

Yeah, I agree that the current approach for cygwin packages isn't communicated properly.

I do have a library libjudy (C library API, no external dependencies) which has not been submitted to the process yet (as I am using this package joe as a process learning exercise). libjudy is expected to be a dependency for another (existing) project in the mingw-w64-x86_64 space. It is not clear if libjudy should be submitted here or over there.

I see, thanks.

libjudy seems to have Windows support, so it can/should go to MINGW-packages, see https://www.msys2.org/dev/new-package/ for how to get started there. libjudy seems abandoned though and from a quick peek at the source seems to assume MSVC on Windows, so some patching/work might be needed get it working.

[dlmiles]

libjudy is feature complete. Not really abandoned, a bit like joe LOL :)

To be abandoned it needs a lists of bug are that not being fixed. However my tree currently has all the patches since the original maintainer/creator did any major work on it, specifically I think it is the only tree with a port to native Win64 (and hopefully GCC/LLVM Win64).

I have a little more testing, with it directly and with the target application that uses it with an autoconf --with-judy option to improve memory usage and performance.