Skip to contentSkip to conversation

package/cryptopp: add Config.in.host

PATCH Superseded Carlos Santos 3 participants 6 messages Dec 12, 2018 – Dec 13, 2018 Tegra architecture support

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore
#0 lore raw

PATCH 1/2 package/cryptopp: add Config.in.host

---
 package/Config.in.host          | 1 +
 package/cryptopp/Config.in.host | 6 ++++++
 2 files changed, 7 insertions(+)
 create mode 100644 package/cryptopp/Config.in.host
package/Config.in.host +1 -0
index 76e619b13e..2211345a7b 100644
@@ -9,6 +9,7 @@ menu "Host utilities"
 	source "package/checksec/Config.in.host"
 	source "package/cmake/Config.in.host"
 	source "package/cramfs/Config.in.host"
+	source "package/cryptopp/Config.in.host"
 	source "package/cryptsetup/Config.in.host"
 	source "package/dfu-util/Config.in.host"
 	source "package/dos2unix/Config.in.host"
package/cryptopp/Config.in.host new file +6 -0
new file mode 100644
index 0000000000..03170cbcf1
@@ -0,0 +1,6 @@
+config BR2_PACKAGE_HOST_CRYPTOPP
+	bool "host cryptopp"
+	help
+	  A free C++ class library of cryptographic schemes
+
+	  https://www.cryptopp.com/
Signature · 1 line
2.19.2
#1 lore raw

PATCH 2/2 package/tegrarcm: select host-cryptopp and drop BR2_arm dependency

- It is not be strictly necessary to select host-cryptopp but let's do it like other host packages do.

- There is no reason to depend on the target architecture, since it's a host tool.

Yes, we could have separate commits to select host-cryptopp and drop BR2_arm dependency but that would be overkill.

---
 package/tegrarcm/Config.in.host | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
package/tegrarcm/Config.in.host +1 -1
index d8cbb947d6..3411501a72 100644
@@ -1,6 +1,6 @@
 config BR2_PACKAGE_HOST_TEGRARCM
 	bool "host tegrarcm"
-	depends on BR2_arm || BR2_armeb
+	select BR2_PACKAGE_HOST_CRYPTOPP
 	help
 	  This program is used to send code to a Tegra device in
 	  recovery mode.
Signature · 1 line
2.19.2
#2 lore raw

PATCH 2/2 package/tegrarcm: select host-cryptopp and drop BR2_arm dependency

Hello,

Quoted 19 lines · Carlos Santos

- It is not be strictly necessary to select host-cryptopp but let's do it like other host packages do.

- There is no reason to depend on the target architecture, since it's a host tool.

Yes, we could have separate commits to select host-cryptopp and drop BR2_arm dependency but that would be overkill.

---
 package/tegrarcm/Config.in.host | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
package/tegrarcm/Config.in.host +0 -0
index d8cbb947d6..3411501a72 100644

package/tegrarcm/Config.in.host line 3

Quoted 3 lines
package/tegrarcm/Config.in.host +0 -1
@@ -1,6 +1,6 @@
 config BR2_PACKAGE_HOST_TEGRARCM
 	bool "host tegrarcm"
-	depends on BR2_arm || BR2_armeb

The idea of this dependency is that since tegracrm is only useful in conjunction with a Tegra-based system, there is not reason to build it if the target isn't ARM.

package/tegrarcm/Config.in.host line 3

Quoted 1 line
package/tegrarcm/Config.in.host +1 -0
+	select BR2_PACKAGE_HOST_CRYPTOPP

So we are starting to add Config.in.host options for all packages ? Why are you doing this change ? What is the motivation ?

Best regards,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
#3 lore raw

PATCH 2/2 package/tegrarcm: select host-cryptopp and drop BR2_arm dependency

Quoted 30 lines · Thomas Petazzoni

Hello,

Quoted 19 lines · Carlos Santos

- It is not be strictly necessary to select host-cryptopp but let's do it like other host packages do.

- There is no reason to depend on the target architecture, since it's a host tool.

Yes, we could have separate commits to select host-cryptopp and drop BR2_arm dependency but that would be overkill.

---
 package/tegrarcm/Config.in.host | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
package/tegrarcm/Config.in.host +0 -0
index d8cbb947d6..3411501a72 100644

package/tegrarcm/Config.in.host line 3

Quoted 3 lines
package/tegrarcm/Config.in.host +0 -1
@@ -1,6 +1,6 @@
 config BR2_PACKAGE_HOST_TEGRARCM
 	bool "host tegrarcm"
-	depends on BR2_arm || BR2_armeb

The idea of this dependency is that since tegracrm is only useful in conjunction with a Tegra-based system, there is not reason to build it if the target isn't ARM.

Quoted 4 lines

package/tegrarcm/Config.in.host line 3

Quoted 1 line
package/tegrarcm/Config.in.host +1 -0
+	select BR2_PACKAGE_HOST_CRYPTOPP

So we are starting to add Config.in.host options for all packages ? Why are you doing this change ? What is the motivation ?

I think it's because I said "We need Config.in.host" :-)

Carlos, the move to Config.in.host is a bit more extensive. We not only need to
add Config.in.host files for all packages, we also need to add selects - which you do here.

Of course we can't do it all in one big shot, but still it should probably be
approached in a somewhat more structured way. For example, when we add a Config.in.host for a package, we also (perhaps in a separate commit) add the select statements for it in all packages that depend on it.

Also note that the idea was to make these Config.in.host options blind (i.e.
promptless).

Regards,
Arnout

#4 lore raw

PATCH 2/2 package/tegrarcm: select host-cryptopp and drop BR2_arm dependency

Quoted 37 lines

From: "Arnout Vandecappelle" <[email protected]>
To: "Thomas Petazzoni" <[email protected]>, "Carlos Santos" <[email protected]>
Cc: "buildroot" <[email protected]>
Sent: Quarta-feira, 12 de dezembro de 2018 7:04:25
Subject: Re: [Buildroot] [PATCH 2/2] package/tegrarcm: select host-cryptopp and drop BR2_arm dependency

Quoted 30 lines · Thomas Petazzoni

Hello,

Quoted 19 lines · Carlos Santos

- It is not be strictly necessary to select host-cryptopp but let's do it like other host packages do.

- There is no reason to depend on the target architecture, since it's a host tool.

Yes, we could have separate commits to select host-cryptopp and drop BR2_arm dependency but that would be overkill.

---
 package/tegrarcm/Config.in.host | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
package/tegrarcm/Config.in.host +0 -0
index d8cbb947d6..3411501a72 100644

package/tegrarcm/Config.in.host line 3

Quoted 3 lines
package/tegrarcm/Config.in.host +0 -1
@@ -1,6 +1,6 @@
 config BR2_PACKAGE_HOST_TEGRARCM
 	bool "host tegrarcm"
-	depends on BR2_arm || BR2_armeb

The idea of this dependency is that since tegracrm is only useful in conjunction with a Tegra-based system, there is not reason to build it if the target isn't ARM.

Quoted 6 lines
Quoted 4 lines

package/tegrarcm/Config.in.host line 3

Quoted 1 line
package/tegrarcm/Config.in.host +1 -0
+	select BR2_PACKAGE_HOST_CRYPTOPP

So we are starting to add Config.in.host options for all packages ? Why are you doing this change ? What is the motivation ?

I think it's because I said "We need Config.in.host" :-)

Right. :-)

Quoted 3 lines

Carlos, the move to Config.in.host is a bit more extensive. We not only need to add Config.in.host files for all packages, we also need to add selects - which you do here.

Yes, tegrarcm is the only package depending in host-cryptopp.

Quoted 8 lines

Of course we can't do it all in one big shot, but still it should probably be approached in a somewhat more structured way. For example, when we add a Config.in.host for a package, we also (perhaps in a separate commit) add the select statements for it in all packages that depend on it.

Also note that the idea was to make these Config.in.host options blind (i.e. promptless).

Make sense if the host package exists only to support building another package (that selects and depends on it) but there are other reasons why a host package may be necessary, e.g. I need host-mtools for a post-image script.

Signature · 1 line
Carlos Santos (Casantos) - DATACOM, P&D
#5 lore raw

PATCH 2/2 package/tegrarcm: select host-cryptopp and drop BR2_arm dependency

Hello Carlos,

Quoted 6 lines · Carlos Santos
Quoted 6 lines

Of course we can't do it all in one big shot, but still it should probably be approached in a somewhat more structured way. For example, when we add a Config.in.host for a package, we also (perhaps in a separate commit) add the select statements for it in all packages that depend on it.

Quoted 7 lines
Quoted 2 lines

Also note that the idea was to make these Config.in.host options blind (i.e. promptless).

Make sense if the host package exists only to support building another package (that selects and depends on it) but there are other reasons why a host package may be necessary, e.g. I need host-mtools for a post-image script.

Yes, of course, we want *some* host packages to be visible in menuconfig.

Basically, the current situation is:

* Most host packages don't have any Config.in.host options (blind or visible), because they are merely build dependencies of other packages.

* A few host packages do have a visible Config.in.host because they are useful by themselves, and not just as a build dependency of something else: image generation tools, flashing tools, qemu, etc.

The idea we have for the future is:

* All host packages have a Config.in.host option.

* The host packages that are only build dependencies of other packages have a blind Config.in.host option

* The host packages that are useful by themselves continue to have a visible Config.in.host option.

Does that clarify where we want to go ?

Best regards,

Thomas Petazzoni

Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com