Hi, I am wondering if there is a way to check how packages were configured before building.
When you run automatic build of TDE the information how a package was build is saved in the xxx.build file, but there are so many and to me it does not look like consistent output.
I want to know if some configuration options were omitted automatically because some dev packages or libraries are missing.
For example tdebindings reported that c# (recommended mono) is missing and therefore bindings for c# will not be build, but it builds the rest.
How can I collect and examine this?
thank and regards
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 2020/03/06 08:33 PM, deloptes wrote:
Hi, I am wondering if there is a way to check how packages were configured before building.
When you run automatic build of TDE the information how a package was build is saved in the xxx.build file, but there are so many and to me it does not look like consistent output.
I want to know if some configuration options were omitted automatically because some dev packages or libraries are missing.
For example tdebindings reported that c# (recommended mono) is missing and therefore bindings for c# will not be build, but it builds the rest.
How can I collect and examine this?
thank and regards
Hi Emanoil, since you are building for debian like distros, start from debian/rules file to see the option passed to make/cmake. Then you can look at the build log output that will list the options/libraries detected and missing. It is very detailed . Cheers Michele
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Michele Calgaro via trinity-devel wrote:
Hi Emanoil, since you are building for debian like distros, start from debian/rules file to see the option passed to make/cmake. Then you can look at the build log output that will list the options/libraries detected and missing. It is very detailed . Cheers Michele
Thank you Michele, but doesn't it look like manual process? Usually the configure script may or may not print the results of the configuration.
Can this be automated?
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On 2020/03/07 04:01 PM, deloptes wrote:
Thank you Michele, but doesn't it look like manual process? Usually the configure script may or may not print the results of the configuration.
Can this be automated?
Hi Emanoil, not sure to understand what you are looking for then... Perhaps you can explain better Cheers Michele
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Michele Calgaro via trinity-devel wrote:
On 2020/03/07 04:01 PM, deloptes wrote:
Thank you Michele, but doesn't it look like manual process? Usually the configure script may or may not print the results of the configuration.
Can this be automated?
Hi Emanoil, not sure to understand what you are looking for then... Perhaps you can explain better Cheers Michele
I think this was correct, what you understood.
For example tdelibs during configuration says
-- Found PCSCLITE: /usr/lib/x86_64-linux-gnu/libpcsclite.so -- Checking for one of the modules 'libcryptsetup' -- Performing Test HAVE_NEW_CRYPTSETUP -- Performing Test HAVE_NEW_CRYPTSETUP - Success -- Performing Test HAVE_CRYPTSETUP_GET_TYPE -- Performing Test HAVE_CRYPTSETUP_GET_TYPE - Success -- Found JPEG: /usr/lib/x86_64-linux-gnu/libjpeg.so (found version "62") -- Found PNG: /usr/lib/x86_64-linux-gnu/libpng.so (found version "1.6.36") -- Found TIFF: /usr/lib/x86_64-linux-gnu/libtiff.so (found version "4.1.0") -- Found Jasper: /usr/lib/x86_64-linux-gnu/libjasper.so (found version "1.900.1")
in many cases there are conditions in the make system (automake or cmake) that will enable or disable an optional feature if the library is found or not found.
How one could know what feature was compiled at the end?
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Sunday 08 of March 2020 11:13:16 deloptes wrote:
Michele Calgaro via trinity-devel wrote:
On 2020/03/07 04:01 PM, deloptes wrote:
Thank you Michele, but doesn't it look like manual process? Usually the configure script may or may not print the results of the configuration.
Can this be automated?
Hi Emanoil, not sure to understand what you are looking for then... Perhaps you can explain better Cheers Michele
I think this was correct, what you understood.
For example tdelibs during configuration says
-- Found PCSCLITE: /usr/lib/x86_64-linux-gnu/libpcsclite.so -- Checking for one of the modules 'libcryptsetup' -- Performing Test HAVE_NEW_CRYPTSETUP -- Performing Test HAVE_NEW_CRYPTSETUP - Success -- Performing Test HAVE_CRYPTSETUP_GET_TYPE -- Performing Test HAVE_CRYPTSETUP_GET_TYPE - Success -- Found JPEG: /usr/lib/x86_64-linux-gnu/libjpeg.so (found version "62") -- Found PNG: /usr/lib/x86_64-linux-gnu/libpng.so (found version "1.6.36") -- Found TIFF: /usr/lib/x86_64-linux-gnu/libtiff.so (found version "4.1.0") -- Found Jasper: /usr/lib/x86_64-linux-gnu/libjasper.so (found version "1.900.1")
in many cases there are conditions in the make system (automake or cmake) that will enable or disable an optional feature if the library is found or not found.
How one could know what feature was compiled at the end?
Here is the fundamental difference between automake × cmake builds.
It is common for automake that there is a choice of "yes / no / auto" - and these are exactly where it is uncertain what features are actually included.
For cmake it is usual that there is a choice of "yes / no" - and if option is set to yes, then building must fail if the conditions are not met - ie, not found libraries, includes, etc. Therefore, cmake building should give certainty what the features are actually included.
Dealing with automation verification for automake building is a waste of time. That's one of the reasons we want to convert everything to CMake.
Verification in CMake should be an essential part that we try to follow. As I mentioned above, there should apply that when conditions are not met for the WITH_* and BUILD_* options, building should always fail in the configuration phase.
Cheers
-
deloptes -
Michele Calgaro via trinity-devel -
Slávek Banko