This makes the whole thing compile _and_ run 🎉.
I have no idea what the ramifications of this are though. But it works?
Also this is like a very quick and dirty 'cleanup'. Things could probably be simplified further, but I'm lazy
Literally just passing the .o files that 'compile' script generates directly to ld.
This is probably a very bad thing and I shouldn't do it this way, but it works for now and allows the linking to at least move on.
Now the next problem is that I have deleted a bunch of 7zip-related stuff that apparently is actually needed:
```
Undefined symbols for architecture x86_64:
"_c_szArcClose", referenced from:
_Ls1Frd_info in Arhive7zLib.o
"_c_szArcGetBoolProperty", referenced from:
_Lc1LuE_info in Arhive7zLib.o
_Lc1MMq_info in Arhive7zLib.o
"_c_szArcGetInt64Property", referenced from:
_Lc1LpL_info in Arhive7zLib.o
_Lc1Ltg_info in Arhive7zLib.o
_Lc1MJs_info in Arhive7zLib.o
_Lc1MKW_info in Arhive7zLib.o
_Lc1N2b_info in Arhive7zLib.o
_Lc1N6l_info in Arhive7zLib.o
_Lc1N7W_info in Arhive7zLib.o
...
"_c_szArcGetStrProperty", referenced from:
_Ls1Fxz_info in Arhive7zLib.o
"_c_szArcGetTimeProperty", referenced from:
_Lc1Lrm_info in Arhive7zLib.o
"_c_szArcItems", referenced from:
_Lc1N3N_info in Arhive7zLib.o
"_c_szCheckType", referenced from:
_Lc1KNu_info in Arhive7zLib.o
"_c_szCompress", referenced from:
_Lc1NlY_info in Arhive7zLib.o
"_c_szDefaultExtension", referenced from:
_Ls1Fp5_info in Arhive7zLib.o
"_c_szExtract", referenced from:
_Lc1Nl4_info in Arhive7zLib.o
"_c_szFindFormatForArchiveName", referenced from:
_Ls1Fqd_info in Arhive7zLib.o
"_c_szOpenArchive", referenced from:
_Lc1KYd_info in Arhive7zLib.o
"_c_szSetBreakFlag", referenced from:
_Arhive7zzLib_setupBreakHandling3_info in Arhive7zLib.o
_Lc1NxT_info in Arhive7zLib.o
_Lc1NY7_info in Arhive7zLib.o
_Lc1OlB_info in Arhive7zLib.o
```
This was pretty stupid of me, I guess. I'd like to get rid of 7zip support completely, but that's a bunch of work
so maybe next I'll try to just bring it back?
Hurray 🎉
These are shitty fixes however, because I've just commented out luaLevel stuff since I don't know wtf it is, and I'm pretty sure the exception handler that I have is also wrong, but let's leave things for now.
Next up: Linking
- Add a `import GHC.Conc.Sync` statement because that module contains `setUncaughtExceptionHandler` apparently
- Repalce GHC.PArr with `vector` usage. I don't know if that's right, but it compiles so it must be?
- More explicit SomeException handlers. These will need to be fixed properly by using appropriate exception types, but later
- A bunch more `@`-without-whitespace fixes
Had to change some stuff in the original sources [^1] but it compiles now:
- Explicit `Control.Monad.mapM`
- `rec` is a keyword in modern Haskell, so I replaced the name with `rec_` where applicable. I think this is right. I don't know anything about Haskell after all.
- A few places where `Utils.sortOn` needed to be qualified again
- `Data.HashTable` -> `Data.HashTable.IO`, but this doesn't actually work because the interface of the new library is wholly incompatible with the old one. No clue what to do about that yet.
- Some places where `@` can't have spaces around it, fixed
- A few places where `Control.Monad.mapM` needed to be qualified
- Remove `FREEARC_CELS` define, whatever the hell it means. It's not used anyway.
- Added `-iCompression/_TABI` to ghc args so that it can find that weird TABI module. Long term I should probably get rid of that nonsense.
What I don't know how to deal with:
- `GHC.PArr` isn't a thing anymore
- New hashtables library does not allow one to specify custom eq/hash functions. Maybe I can copy and paste the old one somewhere.
- Apparently you can't have a space after `@` in the way that it's used. The compiler told me so.
- `Data.HashTable` isn't a thing anymore, but we can use `Data.HashTable.IO` from `hashtables`, which is now a dependency. Some old docs with deprecation messages told me to do this.
- More explicit error types
- `mapM_` is a thing in `Control.Monad`, apparently. No idea what it is, but it compiles.
- `sortOn` is a custom thing in `Utils`, so be explicit.
`FileInfo.hs` and `Options.hs` compile now 🎉
(and I think `Compression.hs` too)
- ByteStream has NOINLINE specified for what seem to be Haskell's abstract methods, which is apparently not allowed. I don't think it's a big deal, so I've commented them out for now.
- A bunch more explicit SomeException types were required in error handling logic in Charsets.hs
- My earlier copy-and-pasted implementation of ignoreErrors wasn't working, so here's a better one that actually works with code that uses it
Apparently modern GHC requires specific exception types everywhere.
From what I can tell the intention of all this code was to catch any exception,
so SomeException it is.
This makes Files.hs compile 🎉
This is mostly about two things:
1. Setting up `cabal`
I basically just set up a new project, moved a bunch of files around and
configured extensions and some libraries that are clearly required.
The original script used `-fglasgow-exts` so I copy and pasted the
extensions this enables from Haskell docs [^1]. Also enabled
`UndecidableInstances`, `OverlappingInstances`, `NoMonomorphismRestriction`
and `BangPatterns` as per the original command line too. And also added
`RecordWildCards` because they were enabled in some modules explicitly.
The basics seem to work.
I had to add dependencies on `old-time` and `old-locale` because there's
a bunch of code relying on those things, and I don't know enough yet to
be capable of modernizing these to use newer supported libraries. I hope
it will work later.
2. Getting `Utils.hs` to compile
This was a bit trickier, but works ultimately:
- I removed all of the byte order stuff because it's not necessary anymore
- Replaced `Data.HashTable.hashString` with `Data.Hashable.hash` because
that's how it's done in modern Haskell apparently
- `sortOn` needed to be qualified for reasons
- Added an explicit type annotation to `handleErrors`, because apparently
modern exceptions require them.
- Replaced `ignoreErrors` implementation with one that I found on the
internet, but I'm not sure it's correct. We'll see later?
[^1]: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/control.html#ghc-flag--fglasgow-exts
Apparently you can use arbitrary expressions in generics in C++, which includes bitshifts. So the compiler gets confused when you have lots of >>> present in your code and you need to put spaces around them to make things work
These are:
- GUIs
- Shell extensions
- FAR plugin (lol)
- Everything that has to do with supporting Windows
- Installers et al.
- Lua support
Things still don't compile though, at least not with a modern toolchain, but the problems seem
smaller than if I had tried to do the lot.
