The following is present inside REQUIRED_USE: ?? ( gl3plus ( || ( gles2 gles3 ) ) ) FWICS, it does the same thing as: gl3plus? ( !gles2 !gles3 ) Was that the intent? Is there a specific reason for writing unreadable insane constructs instead of clearly predictable clauses?
Hmm... My latest OGRE ebuild is in my overlay (seden) for version 1.10.4 mand has the following restraints: REQUIRED_USE=" gl3plus? ( !gles2 !gles3 opengl ) gles2? ( !gl3plus ) gles3? ( !gl3plus gles2 ) poco? ( !tbb threads ) tbb? ( !poco threads ) threads? ( || ( boost poco tbb ) ) " Would they be better? AFAIK these would be valid for OGRE-1.9 as well. Well... now that I read them again, the second line is superfluous (already covered by the first) and the third does (for the same reason) not need "!gl3plus". Further I am a bit puzzled about the last three lines. The background is, that OGRE can use boost (only needs to be detected) for more than just threads, but tell the build system to use poco or tbb as a thread provider. So the boost USE flag can just pull in boost, while poco (or tbb) is used for thread handling. Of course boost can be used for threads, too. Do you have an idea about how to make the last three lines simpler?
(In reply to Sven Eden from comment #1) > Hmm... My latest OGRE ebuild is in my overlay (seden) for version 1.10.4 > mand has the following restraints: > > REQUIRED_USE=" > gl3plus? ( !gles2 !gles3 opengl ) > gles2? ( !gl3plus ) > gles3? ( !gl3plus gles2 ) > poco? ( !tbb threads ) > tbb? ( !poco threads ) > threads? ( || ( boost poco tbb ) ) > " > > Would they be better? AFAIK these would be valid for OGRE-1.9 as well. To be honest, I find those flags seriously confusing and lacking consistency. In particular, it seems that the following combinations are allowed: a. (none), b. opengl, c. opengl + gl3plus, d. gles2 [+ opengl?], e. gles3 + gles2 [+ opengl?]. I don't think many users will be able to figure out what they want. It seems especially weird to me that GLES blocks gl3plus but does not block opengl. > Well... now that I read them again, the second line is superfluous (already > covered by the first) and the third does (for the same reason) not need > "!gl3plus". Yes, you are entirely correct here. Especially with automatic solving in place, it will just prefer USE=gl3plus and the two lines following it would not apply. > Further I am a bit puzzled about the last three lines. > > The background is, that OGRE can use boost (only needs to be detected) for > more than just threads, but tell the build system to use poco or tbb as a > thread provider. > > So the boost USE flag can just pull in boost, while poco (or tbb) is used > for thread handling. Of course boost can be used for threads, too. > > Do you have an idea about how to make the last three lines simpler? Is there any reasonable use case for using an alternate thread provider? If not, I'd just take the easy way out and support boost only.
I've replaced the horrible constraint as described in #c1. Leaving this open for you to further work out how the things should look like eventually. By the way, Sven, wouldn't you be interested in maintaining ogre in gentoo via proxy-maint? commit 46390e0bed7911c493e5da6b915eee55efac6e5b Author: Michał Górny <mgorny@gentoo.org> AuthorDate: Fri Aug 11 18:19:16 2017 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: Fri Aug 11 18:25:18 2017 dev-games/ogre: Fix unreadable REQUIRED_USE, #620912
(In reply to Michał Górny from comment #3) > I've replaced the horrible constraint as described in #c1. Leaving this open > for you to further work out how the things should look like eventually. > > By the way, Sven, wouldn't you be interested in maintaining ogre in gentoo > via proxy-maint? Sure I would! I have an Optimus Laptop, so I always test the sample library through with both Intel Graphics and the discrete nvidia Quadro. (Naturally the latter gives best results. ;-) )
CCing proxy maintainers then (for the case you are still interested)
It seems that the main Ogre development is now between v1.10.x (current stable) and v2.1 (the future). So with 1.8 and 1.9 out the window, I'll have another look at v1.10 and v2.1. I am very interested in both.
I am still on v1.10.11. The good news is, that the build system has changed a lot to the better, and the ebuild will be a lot less complex and less "patchy". With C++11 now the being the minimum standard, doing threads with Boost, tbb or poco has been declared DEPRECATED. So all further discussions can be put down. Cool! The render systems do not interfere any more, so the USE flags merely decide on the dependencies, there does not seem to be a need for restricts in the USE flag combination any more. Very Cool! However, I am facing a strange compilation error. The error has nothing to do with the version of gcc used, the spot failing is simply wrong. But I have not found any bug reports or discussions about it yet, so tonight I'll see whether I can rule out a configuration issue. It is the current stable release, and that should be free of any real errors. Hopefully I'll get through that quickly, because v2.1 is the one I am really after. The CPU-driven times are over, v2.1 utilizes the GPU more thoroughly, resulting in a huge performance boost. I want that for my own projects. :-)
There is a bug for the new versions. For progress on the new ebuilds, please see https://bugs.gentoo.org/647266 The USE flags issue is resolved afaik, so I am closing this.
