Recipe to not install test program and test data

[alonbl]

Hi,

Can you please add conditional to the build system to avoid installing the test program and the test data?

The use case should be:

1. build
2. test
3. install (optional test prog/data)
4. test (if test prog/data is available)

In most cases downstream runs the check during build and these files are not required at root filesystem.

Thanks!

[noloader]

@alonbl ,

Yeah, so I know the problem you are having in the bigger picture. László Böszörményi (@gcsideal) solved it in Debian with Autotools by building two instances of cryptest.exe.

The first instance is called cryptest.exe and it is the one intended to be installed /usr or /usr/local. cryptest.exe is configured so self-tests pass once the library is installed. The second instance is called cryptest-cwd.exe. cryptest-cwd.exe allows testing in the build directory.

In the bigger picture the problem are files in the TestVector/ and TestData/ directories. cryptest.exe needs to open, say, TestVector/aria.txt or TestData/rsa.dat during testing. cryptest.exe opens files /usr/local/share/cryptopp/TestVector/. cryptest-cwd.exe opens files at ./TestVector/.

---

Here is what the code looks like. It is an example of the problem (from validat1.cpp):

bool ValidateAll(bool thorough)
{
    ...
    pass=RunTestDataFile(CRYPTOPP_DATA_DIR "TestVectors/keccak.txt") && pass;
    pass=RunTestDataFile(CRYPTOPP_DATA_DIR "TestVectors/sha3.txt") && pass;
    ...
}

The problem is, CRYPTOPP_DATA_DIR is a macro. At build time it is set to a string like /usr/local/share/.

---

I'm thinking we may need to revisit this. Instead of making folks decide on a value for CRYPTOPP_DATA_DIR (either $PWD or $PREFIX/share), we should perform an intelligent search. I think it may be prudent to try CRYPTOPP_DATA_DIR; and if CRYPTOPP_DATA_DIR fails then try $PWD.

I think @mouse07410 was a proponent of the intelligent search way back when. Ping @mouse07410 and @MarcelRaad for feedback.

[alonbl]

thanks!

[gcsideal]

As Jeffrey (@noloader) noted, Debian compiles cryptest.exe as-is only the name is changed to cryptestcwd.exe . It can be used for testing before the actual installation.
Then it's compiled with the additional -DCRYPTOPP_DATA_DIR='"/usr/share/crypto++/"' to g++ leaving its filename intact and installed to the system. To be honest, the (cryptest.exe) system wide installation happens due to historical purposes. I have doubts anyone or anything uses that after compilation.

[noloader]

@gcsideal,

To be honest, the (cryptest.exe) system wide installation happens due to historical purposes. I have doubts anyone or anything uses that after compilation.

Lol... I've wondered that myself. In the years (decades?) I have been following the library I don't recall anyone using it like, say, openssl. Or I don't recall seeing a question on it.

@alonbl, @gcsideal, @MarcelRaad, @mouse07410,

Is anyone aware of a standard target that installs the library only, and not the library and test program? I did not see one listed at GNU Coding Standards | Standard Targets.

In the absence of a standard target, how does install-lib sound? It will copy the headers, the static archive (if present) and the dynamic library (if present)?

[alonbl]

The build system of your library is non-standard, proprietary and hard to maintain. The absent of standard build system that GNU is using (Autotools) or even cmake is obvious. This is why I was very much surprised that you chose GNU as a reference for that question.

The best practice would have a configure script in which one can specify how build system should behave, including, and not limited to, installing test programs, also obviously toolchain setting (CXX, AR...), location of directories (bindir, libdir) and features (enable-asm).

The build sequence should be as simple as:

./configure <options>
make
make check
make install DESTDIR=...

You can have custom configure script if you hate autotools, but the logic behind the build system is that you state what you need, then build (make) respect that.

Let's take the simple example of the pkg-config target you recently added after long time that it was asked... now it is yet another target of Makefile, I totally missed that since there is no way to extract the options using ./configure --help, one of the users reported that so we have now two targets... actually three as we need all, shared, libcryptopp.pc.

[alonbl]

Deja-vu #327 :)

[noloader]

Cleared at Commit a07a0e5e5f5f.

The old behavior for make install is still in tact. Issuing make install installs cryptest.exe, headers, libcryptopp.a and libcryptopp.so or libcryptopp.dylib. The new target is install-lib, and it installs only headers, libcryptopp.a and libcryptopp.so or libcryptopp.dylib.

[mouse07410]

P.S. I support install-lib target.

[noloader]

@alonbl,

The best practice would have a configure script in which one can specify how build system should behave ...

Yeah, that is actually on my TODO list. When it arrives it will be written in Python and observe the semantics/behaviors of Autotools.

Of all the config scripts I work with on a regular basis, the only one who got it right was Jack Lloyd of Botan (@randombit). Autotools and Cmake have too many problems to use them. Its like throwing away good money on bad. OpenSSL built theirs in Perl but faltered on execution. Not to mention OpenSSL semantics/behaviors change with nearly every version of the library. Using OpenSSL's script is worse than using Autotools or Cmake. The only configuration script I have seen consistently work as expected is Botan's script.

[gcsideal]

@noloader, Python has a not too much up-to-date configuration and build tools list: https://wiki.python.org/moin/ConfigurationAndBuildTools
You may check out SCons if you look for a popular Python based build tool: http://www.scons.org/

[alonbl]

I hear that Meson[1] is the new trend in python.

[1] http://mesonbuild.com/