openssl: support building the binary without MMU

Now that building the openssl binary without MMU is supported, the only reason left for not building apps if the openssl binary is disabled is to save build time. Moreover, the commit 720893b62510438237b9923d744dd079ddb4f67d "openssl: disable apps for NOMMU", which added this behavior, had a side effect: the scripts from apps (CA.pl, CA.sh and tsget) and the default configuration file (openssl.cnf) were no longer installed, which is not advertized by the BR2_PACKAGE_OPENSSL_BIN option. CA.pl and CA.sh use the openssl binary, so not installing them without the latter would make sense. But tsget

Quoted 9 lines · Beno?t Th?baudeau

Now that building the openssl binary without MMU is supported, the only reason left for not building apps if the openssl binary is disabled is to save build time. Moreover, the commit 720893b62510438237b9923d744dd079ddb4f67d "openssl: disable apps for NOMMU", which added this behavior, had a side effect: the scripts from apps (CA.pl, CA.sh and tsget) and the default configuration file (openssl.cnf) were no longer installed, which is not advertized by the BR2_PACKAGE_OPENSSL_BIN option. CA.pl and CA.sh use the openssl binary, so not installing them without the latter would make sense. But tsget

But that's exactly what you're doing here: CA.pl and CA.sh are now installed, even if the openssl binary is not. Also, all the c_* programs in /etc/ssl/misc/ are installed, they call the openssl tool, but the openssl tool is not installed.

tsget and CA.pl are perl scripts, so they cannot work if you don't have a perl interpreter on the target anyway.

So, maybe we need something like:

ifeq ($(BR2_PACKAGE_PERL),)
define OPENSSL_REMOVE_PERL_SCRIPTS

	$(RM) -f $(TARGET_DIR)/etc/ssl/misc/{CA.pl,tsget}

endef
OPENSSL_POST_INSTALL_TARGET_HOOKS += OPENSSL_REMOVE_PERL_SCRIPTS endif

ifeq ($(BR2_PACKAGE_OPENSSL_BIN),)
define OPENSSL_REMOVE_BIN

	$(RM) -f $(TARGET_DIR)/usr/bin/openssl
	$(RM) -f $(TARGET_DIR)/etc/ssl/misc/{c_*,CA.pl,CA.sh}

endef
OPENSSL_POST_INSTALL_TARGET_HOOKS += OPENSSL_REMOVE_BIN endif

No?

Yes. My intent was to keep the rules minimal, but I agree that it is better as you suggest. I will send a v2.

I have a question about the management of the scripts depending on Perl, though. Doing as you suggest hides this behavior in the .mk, so the users won't know that they have a choice just by looking at the configuration. Do you think that it does not really matter, or that a comment or a depends on / select should be added to the Config.in?

Dear Beno?t Th?baudeau,

Quoted 2 lines · Beno?t Th?baudeau

Yes. My intent was to keep the rules minimal, but I agree that it is better as you suggest. I will send a v2.

Great, thanks.

Quoted 5 lines

I have a question about the management of the scripts depending on Perl, though. Doing as you suggest hides this behavior in the .mk, so the users won't know that they have a choice just by looking at the configuration. Do you think that it does not really matter, or that a comment or a depends on / select should be added to the Config.in?

We generally try to not clutter menuconfig with too many comments/options: we can't make visible in menuconfig every little possible dependency. That's why we use a lot of "automatic optional dependencies": a package automatically uses another package if it is available, without having this dependency visible from a menuconfig/Config.in point of view.

I think it's a bit the same here. If you know you need that specific Perl script from OpenSSL, then we assume that you are smart enough to realize that you might need to enable a Perl interpreter for your target.

Yes: we do believe our users are smart! :-)

Thanks,

Thomas

Quoted 6 lines

We generally try to not clutter menuconfig with too many comments/options: we can't make visible in menuconfig every little possible dependency. That's why we use a lot of "automatic optional dependencies": a package automatically uses another package if it is available, without having this dependency visible from a menuconfig/Config.in point of view.

We (or at least, I) do like to have such a thing mentioned in the help text,
however. The help text does not clutter the menus so there is no reason to be terse there.

Arnout,

Quoted 10 lines · Arnout Vandecappelle

Quoted 6 lines

We generally try to not clutter menuconfig with too many comments/options: we can't make visible in menuconfig every little possible dependency. That's why we use a lot of "automatic optional dependencies": a package automatically uses another package if it is available, without having this dependency visible from a menuconfig/Config.in point of view.

We (or at least, I) do like to have such a thing mentioned in the help text,
however. The help text does not clutter the menus so there is no reason to be terse there.

I am perfectly fine with having more details in the Config.in help text.

However, do we really want to explicitly list all automatic optional dependencies in the Config.in help text? I believe it would definitely be hard to maintain.

So the Config.in help text should probably be
mostly used for things that aren't clearly visible by reading the .mk file. And automatic optional dependencies are usually pretty explicit by looking at the .mk file.

Best regards,

Thomas

Quoted 3 lines

However, do we really want to explicitly list all automatic optional dependencies in the Config.in help text? I believe it would definitely be hard to maintain.

Why is it hard to maintain? When you add an automatic dependency to the .mk
file, add it to the Config.in as well. No biggie.

That said, I didn't mean that it should necessarily be added for everything.
But certainly for things that are not immediately obvious. E.g. python support obviously requires python, openssl support is also pretty obvious. Although even there I wouldn't mind mentioning it in the help text.

In this case, on the other hand, it's a tool called 'tsget' that needs perl -
not so obvious.

Quoted 4 lines

So the Config.in help text should probably be
mostly used for things that aren't clearly visible by reading the .mk file. And automatic optional dependencies are usually pretty explicit by looking at the .mk file.

Ugh, I wouldn't like it if we expect from our users that they not only read all
the .mk files of the packages they want to use, but also understand what it all means.

The commit 720893b62510438237b9923d744dd079ddb4f67d "openssl: disable apps for NOMMU" prevented the openssl binary from being built without MMU in order to fix a build failure without fork(). However, openssl is designed to support the lack of fork() with -DHAVE_FORK=0, so allow the openssl binary to be enabled without MMU thanks to this option.

Signed-off-by Beno?t Th?baudeau <[email protected]>

Dear Beno?t Th?baudeau,

Quoted 6 lines · Beno?t Th?baudeau

The commit 720893b62510438237b9923d744dd079ddb4f67d "openssl: disable apps for NOMMU" prevented the openssl binary from being built without MMU in order to fix a build failure without fork(). However, openssl is designed to support the lack of fork() with -DHAVE_FORK=0, so allow the openssl binary to be enabled without MMU thanks to this option.

Quoted 1 line

Signed-off-by Beno?t Th?baudeau <[email protected]>

Hum. But then it means that we have propagated the MMU dependency to all reverse dependencies of openssl (i.e packages that depend on openssl), but they may no longer need this dependency anymore.

There is a fairly huge list of packages that "select BR2_PACKAGE_OPENSSL". How can we find out which ones will now build fine without MMU support ?

By the way, do you have a specific need for openssl on no-MMU platforms? If so, on which platform? We don't have many no-MMU users, so it's good when they speak up :-)

Thanks,

Thomas

Quoted 9 lines · Thomas Petazzoni

Dear Beno?t Th?baudeau,

Quoted 6 lines · Beno?t Th?baudeau

The commit 720893b62510438237b9923d744dd079ddb4f67d "openssl: disable apps for NOMMU" prevented the openssl binary from being built without MMU in order to fix a build failure without fork(). However, openssl is designed to support the lack of fork() with -DHAVE_FORK=0, so allow the openssl binary to be enabled without MMU thanks to this option.

Quoted 5 lines

Quoted 1 line

Signed-off-by Beno?t Th?baudeau <[email protected]>

Hum. But then it means that we have propagated the MMU dependency to all reverse dependencies of openssl (i.e packages that depend on openssl), but they may no longer need this dependency anymore.

This is only about BR2_PACKAGE_OPENSSL_BIN, which is not selected by any package.

Quoted 7 lines

There is a fairly huge list of packages that "select BR2_PACKAGE_OPENSSL". How can we find out which ones will now build fine without MMU support ?

By the way, do you have a specific need for openssl on no-MMU platforms? If so, on which platform? We don't have many no-MMU users, so it's good when they speak up :-)

Quoted 3 lines

Hum. But then it means that we have propagated the MMU dependency to all reverse dependencies of openssl (i.e packages that depend on openssl), but they may no longer need this dependency anymore.

This is only about BR2_PACKAGE_OPENSSL_BIN, which is not selected by any package.

The commit 720893b62510438237b9923d744dd079ddb4f67d "openssl: disable apps for NOMMU" prevented the openssl binary from being built without MMU in order to fix a build failure without fork(). However, openssl is designed to support the lack of fork() with -DHAVE_FORK=0, so allow the openssl binary to be enabled without MMU thanks to this option.

Signed-off-by Beno?t Th?baudeau <[email protected]>

---
 package/openssl/Config.in  | 3 ---
 package/openssl/openssl.mk | 4 ++++
 2 files changed, 4 insertions(+), 3 deletions(-)