Re: [Chicken-users] Building the openssl egg on MacOS

[Lassi Kortela]

> 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?