I didn't see an explicit issue around this and I apologize if this is kicking up a hornets' nest (and it probably is), but this seems long overdue.
For users that really need 32 bit support, maintaining a fork seems like the right way to go. This is the same for any older architectures (PPC, for example) that might still be in the code base (BC code, for example)
I believe this would make it easier to update libraries like GTK which could help programs like DrRacket (which is showing its age) a great deal. Also, it could make things like evaluating libuv for async io, thread and thread pool support much easier.
Also, it would reduce the official build targets and reduce the amount of testing needed for those targets.
As an aside, I would highly suggest the team look at adopting CMake and vcpkg for managing external C libraries. Yes, vcpkg is a Microsoft open source tool, but it is cross platform. A large amount of the libraries are supported out of the box already.
Thanks for the suggestion, but I doubt that ending support for 32-bit platforms would do much for updating the GUI libraries for Racket and DrRacket. More generally, the way that Racket is put together is different than it sounds like you imagine.
For example, there's no difficulty with getting the makefiles right for linking to Gtk, because the Racket executable is not linked to Gtk. Platform-native GUI libraries are dynamically loaded and accessed directly from Racket code at run time. Similarly, the difficulty of adding parallel threads and pools to Racket wasn't in needing a more portable layer on C threads, but that C threads (including a limited-size stack) are mismatched to Racket's continuations; the work is generally only the compiler and scheduler side for managing continuations. GUI and scheduling come together in the racket/gui support for "eventspaces", which lets us have multiple process-like tasks within Racket (consider DrRacket and a program that it's running), but that also fights against the way platform-specific GUI libraries want to to be used.
There are possibly parts of libuv that would be useful to Racket, and a modernization of the Racket drawing and GUI libraries certainly would be helpful. But the work is really specifically about using the libraries and bridging abstractions in Racket, and not so much about how to build and link the libraries.
Thanks for the explanation. If maintaining 32-bit builds isn't that much of a burden and fundamentally isn't a road block for updating external libraries, that's great.
I would still suggest that moving towards vcpkg is a good idea. I understand why that is difficult given the number of patches in the racket source code for libraries, but I would think that is technical debt to be reduced. I can poke around with it a bit just to see if there are any obvious flaws.
Libuv just happened to be on my mind, it was just an example. Using it for non-blocking IO probably is worth investigating once the work on the OS thread and thread pool is more established.
I certainly understand that there are issues around the GUI library that are larger than bumping up the GTK versions.
Sadly, for personal reasons, I have little time to contribute to helping with these issues, much less than I would like. So, again, your time is appreciated.
What exactly are you thinking we would use vcpkg for? Racket has very few build-time C/C++ dependencies (libcurses, libpthread, and libiconv are the important ones on Linux). Other C library dependencies are loaded dynamically at runtime which doesn't really fit with the vcpkg workflow.
If you're instead suggesting that this code could be simplified with vcpkg then that could well be helpful but I think I'd need to see it to believe it -- there's a lot of fragility with building other C software.
Looking at it, the most value would be for tracking and building the native libraries (and their dependencies) that are packaged for Racket to be loaded dynamically. I think that could be very useful. You just need a vcpkg.json file and a couple of vcpkg commands that use MSBuild, CMake or XCode to build and place those libraries in a standard directory layout.
raco could even be made aware of those conventions and use it to determine what native libraries to use when installing a package. So, arch-os specific raco packages for the same libraries could be eliminated. It also provides guidance on how a third-party package that uses custom dynamic libraries should be built and organized. It doesn't force the use of vcpkg if the package respects the directory organization, of course.
I still think there's some misunderstanding here. Packages like "db-win32-x86_64" contain the actual binary versions of the libraries; they don't build them at installation time. We don't want to ask people to build things with a C compiler at install time. You can see the contents of those packages here: libs/db-win32-x86_64 at master · racket/libs · GitHub
The actual build process for those binary libraries in in the link that I gave earlier, which could use a different build system if vcpkg or something else would help.
There are still a lot of machines on the market with only 4G of RAM.
That can be addressed with 32 bits of address.
Lisp involves pointer-heavy data.
Expanding addressing to 64 bits would effectively reduce Lisp memory by a faxtor of two.
No, I understand that the packages have binaries in them, not source. I was talking about consolidating the packages so that the needed binaries for different arch-OS combinations would be in one raco package.
The raco package tool would then grab and extract only the appropriate binaries. The fact that the layout of the directories in the package itself matches how vcpkg places built binaries in a project is just reusing a convention that is well established.
If you were developing a package with dynamic libraries, then you can use vcpkg to greatly simplify the build and packaging (for raco) of those libraries without forcing the use of any tool as long as the conventions are met.
If there aren't enough people using that workflow, then yes, you can have arch-os-specific packages and require 32 bit versions to support every possible arch-os target that racket supports.
Does that mean that when installin Racket I end up downloading binaries for
lots of architectures rather than just the one I am using?
Will I stil be able to download binaries for other architectures in case I
have to download on a differenf machine than I will be instaling on?
I still think there's some failure of communication between us, but I think the best way to clarify would be for you to write a patch demonstrating how you are proposing to change things.
Looking at it, the best way to go about this would be to first replace the build step for native libraries (the code you linked to) first. I can do a poke at it as proof of concept.
If that moves forward, that would inform how other packages with native libraries may or may not change.