Created attachment 199470 [details]
Use /usr/local/include/leatherman/vendor before /usr/local/include
Build of sysutils/facter fails when devel/rapidjson is installed in the system.
Command which fails and error message:
cd /usr/ports/sysutils/facter/work/facter-3.12.1/lib && /usr/bin/c++ -DBOOST_ALL_DYN_LINK -DBOOST_LOG_WITHOUT_WCHAR_T -DBOOST_SYSTEM_NO_DEPRECATED -DLEATHERMAN_I18N -DLEATHERMAN_LOGGING_NAMESPACE=\"puppetlabs.facter\" -DLEATHERMAN_USE_LOCALES -DPROJECT_DIR=\"/usr/ports/sysutils/facter/work/facter-3.12.1\" -DPROJECT_NAME=\"FACTER\" -DUSE_CPPHOCON -DUSE_JRUBY_SUPPORT -DUSE_OPENSSL -DUSE_YAMLCPP -Dlibfacter_EXPORTS -I/usr/ports/sysutils/facter/work/facter-3.12.1/lib/inc -I/usr/ports/sysutils/facter/work/facter-3.12.1/../vendor/nowide/include -I/usr/local/openjdk8/include -I/usr/local/openjdk8/include/freebsd -I/usr/local/include -I/usr/local/include/leatherman/vendor -Wno-deprecated-register -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wno-tautological-constant-out-of-range-compare -O2 -pipe -O2 -pipe -march=haswell -fstack-protector -fno-strict-aliasing -O2 -pipe -O2 -pipe -march=haswell -fstack-protector -fno-strict-aliasing -fPIC -o CMakeFiles/libfactersrc.dir/src/facts/resolver.cc.o -c /usr/ports/sysutils/facter/work/facter-3.12.1/lib/src/facts/resolver.cc
--- lib/CMakeFiles/libfactersrc.dir/src/facts/external/json_resolver.cc.o ---
In file included from /usr/ports/sysutils/facter/work/facter-3.12.1/lib/src/facts/external/json_resolver.cc:9:
/usr/local/include/rapidjson/reader.h:1340:32: error: no member named 'RawNumber' in 'facter::facts::external::json_event_handler'
cont = handler.RawNumber(str, SizeType(length), false);
/usr/local/include/rapidjson/reader.h:1401:23: note: in instantiation of function template specialization 'rapidjson::GenericReader<rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator>::ParseNumber<0, rapidjson::FileReadStream, facter::facts::external::json_event_handler>' requested here
/usr/local/include/rapidjson/reader.h:501:13: note: in instantiation of function template specialization 'rapidjson::GenericReader<rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator>::ParseValue<0, rapidjson::FileReadStream, facter::facts::external::json_event_handler>' requested here
/usr/local/include/rapidjson/reader.h:527:16: note: in instantiation of function template specialization 'rapidjson::GenericReader<rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator>::Parse<0, rapidjson::FileReadStream, facter::facts::external::json_event_handler>' requested here
return Parse<kParseDefaultFlags>(is, handler);
/usr/ports/sysutils/facter/work/facter-3.12.1/lib/src/facts/external/json_resolver.cc:211:30: note: in instantiation of function template specialization 'rapidjson::GenericReader<rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator>::Parse<rapidjson::FileReadStream, facter::facts::external::json_event_handler>' requested here
auto result = reader.Parse(stream, handler);
1 error generated.
*** [lib/CMakeFiles/libfactersrc.dir/src/facts/external/json_resolver.cc.o] Error code 1
It is possible to see that -I/usr/local/include has been put before -I/usr/local/include/leatherman/vendor
As the result /usr/local/include/rapidjson/reader.h is included instead of /usr/local/include/leatherman/vendor/rapidjson/reader.h
Attached patch fixes this problem by moving -I/usr/local/include/leatherman/vendor in front of -I/usr/local/include
If there's a way to make user supplied *FLAGS (CFLAGS, CPPFLAGS, LDFLAGS, et al) all and always come *last*, that would be preferable over making specific includes come first/before.
Alternatively and better, under the assumption that cmake doesn't clobber user-supplied flags by default or when used properly in a standards compliant / by convention manner, then identifying and fixing whatever the facter's build system files do that clobber these flags would be ideal (and then sending it upstream), treating this issue as 'honour user-supplied flags', meaning they always come last to override the build system provided/derived values.
I might be wrong, but to me it looks like "-I/usr/local/include" is not part of user supplied flags. It is rather included into each of the following variables which are constructed/identified by cmake and later supplied into include_directories() command:
I got some time to look at this and I tried to reproduce the problem today, but it seems that the build succeed, rapidjson being installed or not on the system (FreeBSD 11.2, ports from few days ago).
The committed changes to the port between the PR creation and now seems unrelated, so their was either some problem in the ports framework itself that got fixed, or your local setup make something go wrong.
Can you please try again and report success or failure?
Thanks for looking into this.
I retried with fresh ports and I was able to reproduce original problem on 12.0-RELEASE-p2 and 13.0-CURRENT hosts.
To make sure this is not something related to FreeBSD base version I made a test on VM image of 11.2-RELEASE downloaded from freebsd.org and it still fails for me.
I've executed only following steps to trigger this issue on fresh VM:
portsnap fetch extract
pkg install -y rapidjson cmake openjdk8 dialog4ports ruby boost-libs leatherman cpp-hocon yaml-cpp
A commit references this bug:
Date: Sat Jan 12 06:39:42 UTC 2019
New revision: 490027
Fix build when devel/rapidjson is installed
devel/leatherman include an old version of RapidJSON that is not compatible
with what devel/rapidjson install. Reorder includes so that the version
included with devel/leatherman is found before the one of devel/rapidjson
because it is what is wanted.
While here, fix `make test`.
No need to bump PORTREVISION.
Reported by: firstname.lastname@example.org
I mixed up leatherman and facter and ending up verifying leatherman was building correctly. Indeed it does.
So, I could reproduce the problem and see that the proposed fix seems to improve the situation ;-) After more testing, it looks like just reordering the includes does the trick, so I committed this.
Thank you for your report!
Thank you for your efforts
I retried from scratch with the FreeBSD 11.2 VM and fresh ports (where patch-lib_CMakeLists.txt is already present) and I still see original problem.
For some reason just reordering includes doesn't fix the problem for me.
Reopen, more test needed
Yeah, I can reproduce this in a clean jail. Maybe ccache is tricking on me on my usual test environment :-/.
A commit references this bug:
Date: Sun Jan 13 03:33:12 UTC 2019
New revision: 490112
Fix build when rapidjson is installed (again)
Submitted by: email@example.com
This will hopefully definitively fix this issue!
For your information, there is some traction upstream for unvendoring rapidjson from leatherman [1, 2]. I guess this would make this kind of changes useless, so would allow us to remove that patch in the future. As a consequence, I will not try to have that change merges upstream.
Thanks a lot Romain!