Opened 6 years ago
Last modified 4 years ago
#57117 new enhancement
upgrade last users of protobuf-cpp to protobuf3-cpp
Reported by: | pmetzger (Perry E. Metzger) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | mojca (Mojca Miklavec), stromnov (Andrey Stromnov), lockhart (Thomas Lockhart) | |
Port: | shogun-devel sumo |
Description (last modified by mf2k (Frank Schima))
Ignoring things that are supposed to have the dependencies (like protobuf-java or py-protobuf), the following six ports still seem to have protobuf-cpp dependencies:
Direct:
port | maintainer | status |
---|---|---|
opencv | @stromnov,openmaintainer | |
raceintospace | ||
shogun-devel | @stromnov,openmaintainer |
Indirect via py27-protobuf:
port | maintainer | status |
---|---|---|
caffe | ||
MyPaint | @ryandesign,openmaintainer | |
sumo | @lockhart,openmaintainer |
Change History (19)
comment:1 Changed 6 years ago by mojca (Mojca Miklavec)
Cc: | mojca added |
---|
comment:2 Changed 6 years ago by mf2k (Frank Schima)
Description: | modified (diff) |
---|---|
Port: | caffe MyPaint opencv raceintospace shogun-devel sumo added |
Type: | defect → enhancement |
comment:3 Changed 6 years ago by pmetzger (Perry E. Metzger)
comment:4 Changed 6 years ago by mojca (Mojca Miklavec)
Cc: | stromnov ryandesign lockhart added |
---|
comment:5 follow-up: 6 Changed 6 years ago by kencu (Ken)
for some of these, switching to protobuf3-cpp and then just forcing the build to clang-7.0 (or newer) might be the easiest way out.
clang-7.0 defaults to a newer c++ standard, so you don't need to monkey around with the build system, for example, caffe
57093.
Naturally, fix it all up if you want, but it's pretty simple to just switch up the compiler and you're done...
comment:6 follow-up: 7 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)
So I guess what wasn't said in the ticket, but which I recall from previous discussion, is that protobuf3-cpp requires C++11 now, so everything that uses it does too, and needs the cxx11 1.1 portgroup at least.
Replying to kencu:
for some of these, switching to protobuf3-cpp and then just forcing the build to clang-7.0 (or newer) might be the easiest way out.
clang-7.0 defaults to a newer c++ standard, so you don't need to monkey around with the build system, for example,
caffe
57093.Naturally, fix it all up if you want, but it's pretty simple to just switch up the compiler and you're done...
As always, don't force specific compilers (e.g. by setting compiler.whitelist
or configure.compiler
). Instead, use compiler.blacklist
to list the compilers that don't work, and if necessary, add a working compiler to compiler.fallback
.
The problem you pointed out with caffe was that we needed to add -std=c++11
to the compile flags somewhere. Since protobuf3-cpp apparently requires C++11 now, shouldn't it be arranging for -std=c++11
to appear in the compile flags?
comment:7 Changed 6 years ago by kencu (Ken)
Replying to ryandesign:
shouldn't it be arranging for
-std=c++11
to appear in the compile flags?
Sure. I fixed half a dozen ports like that already. But caffe
is a mess. Maybe easy for you, but an hour for me and no success.
My contribution is that forcing one of those new compilers is a simple fix, when you're in Makefile hell.
comment:8 follow-up: 10 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)
My point was: isn't it protobuf3-cpp's responsibility, not the responsibility of caffe or the caffe portfile or of any other software that uses protobuf3-cpp, to specify the -std=c++11
flag? If we fix this at one central place, in protobuf3-cpp, isn't that a simple fix?
comment:9 Changed 6 years ago by lockhart (Thomas Lockhart)
Looking at the sumo port now, to upgrade sumo to 1.0.1 and to use python3 and protobuf3. So far the results are promising.
comment:10 Changed 6 years ago by kencu (Ken)
Replying to ryandesign:
My point was: isn't it protobuf3-cpp's responsibility, not the responsibility of caffe or the caffe portfile or of any other software that uses protobuf3-cpp, to specify the
-std=c++11
flag? If we fix this at one central place, in protobuf3-cpp, isn't that a simple fix?
Ah, I get you now. Turns out, no. The port that is using protobuf3-cpp has to now be built with -std=c++11
so it can properly process the protobuf 3.6.1+ headers.
comment:11 follow-up: 13 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)
Yes. And the port that is using protobuf3-cpp should probably be asking protobuf3-cpp what flags it should be using to do that, such as by using pkg-config, right? I'm suggesting putting the flag in protobuf.pc (and protobuf-lite.pc if applicable).
comment:12 Changed 6 years ago by mojca (Mojca Miklavec)
That won't be a completely fool-proof solution either. While pkg-config
may return -std=c++11
, it won't be able to tell MacPorts that some compilers need to be blacklisted.
(I did this in the wxWidgets PortGroup, but it's probably not worth creating a PortGroup in this case.)
comment:13 follow-up: 14 Changed 6 years ago by kencu (Ken)
Replying to ryandesign:
I'm suggesting putting the flag in protobuf.pc (and protobuf-lite.pc if applicable).
At first glance, I can see the logic in that. However, what if the port using protobuf actually needs -std=c++14
or some newer standard than that? Then that flag from protobuf would mess things up...
I looked in my pkgconfig directory, and found that only icu
passed in a -std=c++N
flag out of all the *.pc files in there.
In addition, it seems that pkg-config is not currently set up to (easily) pass CXXFLAGS <https://stackoverflow.com/questions/46550299/why-doesnt-pkg-config-support-cxxflags>...
comment:14 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to kencu:
Replying to ryandesign:
I'm suggesting putting the flag in protobuf.pc (and protobuf-lite.pc if applicable).
what if the port using protobuf actually needs
-std=c++14
or some newer standard than that? Then that flag from protobuf would mess things up...
Upon reflection, you're probably right. Which leaves us back with needing to fix each port that uses protobuf individually.
In addition, it seems that pkg-config is not currently set up to (easily) pass CXXFLAGS <https://stackoverflow.com/questions/46550299/why-doesnt-pkg-config-support-cxxflags>...
Amazing. It's a wonder anything builds at all!
comment:15 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ryandesign removed |
---|---|
Port: | caffe MyPaint opencv removed |
caffe was fixed in [927b4ccc53a51898999d816af30a9ecceda6ea7c/macports-ports]
opencv was fixed in [d98d7d7369a9f350c609082d8e1147c47831edc1/macports-ports]
MyPaint was fixed in [c7c14efc3a55a380f871bbed2e0952116fc981e2/macports-ports]
comment:16 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Port: | raceintospace removed |
---|
raceintospace was fixed in [8029a3a23bf2d1cc3e3511d60fa0b0d679a73082/macports-ports]
comment:18 Changed 4 years ago by kencu (Ken)
was caffe actually fixed? I think we just default now to a compiler that defaults to >= c++11 --- which is where we started with this plan!
Sometimes, that truly is the simplest fix, if not pure.
comment:19 Changed 4 years ago by lockhart (Thomas Lockhart)
Replying to pmetzger:
sumo @lockhart,openmaintainer
The newer versions of sumo do not seem to require protobuf of any sort. I've got patches to build the newest version; will try to get them into github asap.
Frank, thanks for that edit, it's easier to look at now!