I maintain the openssl egg these days.
Very nice, thanks for your efforts!
Ugh. I've always had the impression macOS gets worse with each release,
but this is ridiculous, almost as if they expect everyone to use XCode
for development...
I find that the usability gets better with each release (still dreading
the inevitable downfall) but from a programmer's point of view it does
indeed get worse. Mojave locked down some files so even with sudo you
can't touch them, deprecated other stuf, and retroactively made it so
you need the App Store login to install the full XCode.
The easiest workaround is to install a copy of OpenSSL or LibreSSL from the
popular Homebrew package manager and build the egg using that copy:
This is what I recommend to everyone who has to work on that kind of
system. It's sad, but the least painful way of getting work done.
Cool, I didn't know that.
Homebrew is actually really nice to use, but your point stands about the
state of MacOS itself.
I hereby reiterate my point that doing development on macOS involves
much sadness, such as creating a developer account to do development.
I'm afraid there isn't much else you can do, unless you somehow get gcc
and the rest of the toolchain working without that.
The command-line compilers (clang, swiftc) are available without an App
Store login as before ("sudo xcode-select --install"). But the XCode IDE
is apparently not. As for the OpenSSL headers, I don't know whether they
are intentionally gone for good or only available from the App Store
(and can't tell which is worse :)
would it make sense to add MacOS-specific checks to the build-openssl script?
Before you do that, there is some work I've done on a few more eggs I
maintain, I got fed up with writing user-unfriendly shell scripts that I
rewrote the non-Windows version to use a Scheme program instead
That sounds like a wise move. And for us who maintain Scheme-related
infrastructure, it's nice to get the chance to actually write some
Scheme code every now and then :) It so often happens that the C/shell
parts take the most time.
basic version detection, falling back to environment variables and
finally bailing out with an error. You can find the latest version of
it at the breadline repository [1]. Please let me know if that fulfills
your wishes and if not, whether it can be made to do so. If yes, then
I'd be willing to migrate the openssl egg towards such a script as well.
The reason I haven't done so is because unlike the other eggs I maintain
it's something I'd rather not touch unnecessarily, breakages to it will
be far more annoying to handle than anything else. And honestly
speaking, OpenSSL isn't nice to deal with either :>
Thank you for inviting feedback! I'll definitely help work things out.
I was thinking, even without considering OpenSSL at all, dealing with
pkg-config by itself is complicated enough that it might be worth baking
special pkg-config support into chicken-install (or whatever the right
internal module is that chicken-install uses).
Some of the BSD's re-implemented the original glib-based pkg-config as
"pkgconf". Luckily, pkgconf installs a pkg-config command as a
compatibility wrapper and it seems quite feature-complete (in the same
way that libressl is with openssl, or clang is with gcc). I haven't had
any problems with pkgconf.
But several OSes don't ship with pkg-config by default, so users have to
install it. In order to be user-friendly, it'd be nice if Chicken
advised them on how to do it. (If Chicken has all the pkg-config
business in one place, instead of separately in each egg, then it's a
very modest amount of code to provide a user-friendly experience.)
I would tentatively recommend supporting pkg-config as the only way to
specify compiler and linker flags for C libraries. I've always thought
that users should have the option to give flags manually instead of
relying on pkg-config. But today I realized that pkg-config .pc files
are basically simple .ini files that contain little more than those same
flags. So if users want manual overrides, we could just ask them to
write their own .pc file and set PKG_CONFIG_PATH to find it.
Also .pc files specify the library version. E.g. the openssl egg
requires openssl 1.0.2 or later, which it can check from the .pc file.
(It's not reliable to check using the "openssl" shell command, since
that may be a different version.) With user-supplied CFLAGS and LDFLAGS
we can't easily make this version check. The .pc file is unlikely to
have the wrong version number unless the user deliberately messes it up
or makes up an arbitrary version number.
But is stuff detailed enough that it should be discussed on the
"hackers" mailing list?
_______________________________________________
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users