cegui version 0.7.0 has been released http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=4340 Reproducible: Always
Created attachment 205439 [details] ebuild that compiles correctly as far as i know this ebuild was converted from the privious versioned ebuild. it compiles but i have no idea on how to test cegui yet
Some additional things to note: 0.7.0 is massively interface breaking, so any code - either user code or other packages in portage - using the previous 0.6.2b and earlier will not compile cleanly against the new CEGUI version without some modification. Due to the above, CEGUI binary versioning is switched to use release numbers; it's now easier to have side-by-side / slotted binary installs (for example, of the old 0.6.2b and the new 0.7.0). Although it's left up to distro maintainers if side-by-side / slotted installs of the development headers is desired (as it likely would be for Gentoo). A few new configure options are added: some make freetype2 and pcre optional (not recommended for normal use), others allow configuration of an optional suffix to be added to the binary output, and another to control the version number added (defaults to the full release number, some may opt to change this to be less fine-grained). DirectFB support is currently broken.
Created attachment 207243 [details] experimental slotted ebuild with directfb disabled @Paul i had to correct some Makefile.am's to handle $(includedir) correct.
Created attachment 207300 [details, diff] patch to fix external tiny xml lib support. (In reply to comment #3) > @Paul i had to correct some Makefile.am's to handle $(includedir) correct. Thanks for the info. I'll perhaps fix this in our tree for the soon to be released 0.7.1. I've attached a patch needed for TinyXML support to compile cleanly against the newer external TinyXML lib (2.5.3 which is currently ~amd64). Aside, from this the ebuild seems to work ok for me, though I've not tested thoroughly at all.
(In reply to comment #4) > I've attached a patch needed for TinyXML support to compile cleanly against the > newer external TinyXML lib (2.5.3 which is currently ~amd64). > Seems this patch is only needed for gentoos version of tinyxml 2.5.3_p20090813. the upstream release version 2.5.3 doesnt need this patch.
*** Bug 291953 has been marked as a duplicate of this bug. ***
Created attachment 229275 [details] cegui-0.7.1.ebuild Little modified ebuild from Bug 291953, with media-libs/freeimage support. The media-libs/freeimage support is "brutal force", but it works - I hope somebody make it better.
Created attachment 229299 [details] cegui-0.7.1.ebuild bug correction - without freeimage use flag (and media-libs/freeimage - Bug 307487) we won't have pkg-config freeimage
Created attachment 230717 [details] cegui-0.7.1.ebuild Now it forces to find freeimage...
Created attachment 231701 [details] cegui-0.7.1.ebuild The slot option was good...
Just a comment as regards to the use of --enable-static when configuring. In this version (and previous versions, actually) you end up in a situation where an app attempting to statically link CEGUI would still dlopen some shared libs from the package at runtime which are linked to the other shared libs and you thus end up with a non working app. This issue is mainly due to the static build needing a specific set up to work correctly (basically CEGUI_STATIC being defined), and the shared build definitely not wanting this. Or to put it another way, in 0.7.1 and earlier, using the static libs will not work reliably. And as a heads up for future versions: the static build will work correctly, although enabling the static build requires explicit use of --disable-shared to disable the shared build; i.e. you can't make both at the same time. IMO you should go with the shared libs and forget about the static libs.
(In reply to comment #11) But enabling static you can use both shared and static. (We aren't disabling shared libs)
(Correction to comment #12) So you suggest to add "static" or "static-libs" USE flag which will enable static and disable shared libs?
What I'm saying is that for the CEGUI 0.7.1 release (and earlier) the static libs produced will not work correctly; linking the static CEGUIBase will still attempt to use dlopen at runtime to load the shared version of certain other libs from CEGUI which are themselves linked to the shared version of the CEGUIBase library. I was additionally giving forward notice that from CEGUI version 0.7.2, to be released later this year, the static builds will be working, but they can't be built at the same time as the shared libs. Whether at this later time providing a 'static' use flag would be useful, I will leave for others to decide. To correctly link CEGUI statically to other code requires more than just linking the .a file instead of the .so file. If you go the route of the use flag, this should also then add -DCEGUI_STATIC in the CFlags of the CEGUI.pc file. (Though again I reiterate: not for 0.7.1. Static libs should be treated as broken in all releases up to and including 0.7.1). By giving input here I am merely attempting to offer insight into how things are now and how things are moving in the future so as to attempt to avoid future support headaches for both gentoo and CEGUI.
Created attachment 231709 [details] cegui-0.7.1.ebuild Ok, so when the 0.7.2 version will be released I will add a static use flag
hi! thanks for working on the ebuild! would be nice if you could also attach cegui-0.7.1-tinyxml.patch and cegui-0.7.1-pkgconfig.patch
Created attachment 235915 [details, diff] dev-games/cegui/files/cegui-0.7.1-tinyxml.patch
Created attachment 239503 [details, diff] cegui-0.7.1-pkgconfig.patch Patch from bug 291953
I'm not sure if I should have opened a new bug here or reply to this bug as I am now, but I made a few minor modifications to update it for 0.7.5.
Created attachment 261055 [details] CEGUI 0.7.5 ebuild
Created attachment 261057 [details, diff] pkgconfig patch for CEGUI 0.7.5 ebuild
Created attachment 261058 [details, diff] TinyXML patch for CEGUI 0.7.5 ebuild
(In reply to comment #2) > Some additional things to note: > > 0.7.0 is massively interface breaking, so any code - either user code or other > packages in portage - using the previous 0.6.2b and earlier will not compile > cleanly against the new CEGUI version without some modification. > > Due to the above, CEGUI binary versioning is switched to use release numbers; > it's now easier to have side-by-side / slotted binary installs (for example, of > the old 0.6.2b and the new 0.7.0). Although it's left up to distro maintainers > if side-by-side / slotted installs of the development headers is desired (as it > likely would be for Gentoo). Theoretically, having slotted installs could be beneficial to some people, but as I've been using CEGUI for compiling other programs, I have found that I have to use symlinks and update them manually whenever I update my version, such as from 0.7.1 to 0.7.3 or 0.7.5. It is honestly much easier to have it unslotted because otherwise programs that need CEGUI don't seem to be able to find the libraries or include files in the non-default directories. I've modified the ebuild on my local overly to be unslotted for this reason. The only way I can see for slotted ebuilds of CEGUI to be manageable is if there is an eselect module for CEGUI that automatically makes symlinks to the default locations. Is this doable?
I will update on the things from the view of the CEGUI project: Later this year we will release the first of the 0.8.x series of releases. This will contain massive breaking changes from the 0.7.x series. With 0.8.x we are moving /away/ from having release numbers in the library name, and switching back to more traditional / conventional naming and versioning - such that when we do release binary compatible patch releases, people can update to those without breaking everything on their system that uses CEGUI (more of an issue on binary based distros). The issue of slotted installs (or not) is mainly an issue for source based distros like Gentoo. Due to incompatibilities between versions of CEGUI, if you had 0.7.x installed, and today tried to emerge some package that uses CEGUI, it will fail to build - so there needs to be a solution of some kind. I like the eselect idea, I'd actually mentioned this to someone the other day on IRC. So all things considered, a slotted install with an eselect module would certainly be a way forward in my opinion. For info: I am the project leader for CEGUI and a Gentoo user. Though I am /not/ the maintainer of this package in Gentoo ;)
(In reply to comment #24) > So all things considered, a slotted install with an eselect module would > certainly be a way forward in my opinion. > > For info: I am the project leader for CEGUI and a Gentoo user. Though I am > /not/ the maintainer of this package in Gentoo ;) > For what it's worth, I filed a separate bug for an eselect module: http://bugs.gentoo.org/show_bug.cgi?id=355137 . Hopefully this will get sufficient attention. Sometimes, you have to just do it yourself if you want it done. Unfortunately I'm lucky if can make some minor working changes to an ebuild. Writing an eselect module is definitely not something I'm currently capable of!
alternatively, we could just punt packages that dont keep up. SLOT-ed libraries make sense when upstream is doing the same, but if cegui upstream isnt doing that, then it's quite a lot of hassle on our side. an eselect module doesnt magically make these problems go away. every package in the tree that uses cegui will need manual patching that Gentoo will be forced to carry forever. we only have 3 packages in the tree that use cegui: dev-games/ogre dev-games/crystalspace games-arcade/smc which means it should be fairly easy to make sure those work with the latest cegui, or we drop them from the tree. thus SLOT-ing sounds like a waste of our resources.
Comment on attachment 261055 [details] CEGUI 0.7.5 ebuild some issues with this ebuild: - DESCRIPTION is way too long - EAPI must be before inherit - dont drop ppc - IUSE=static -> IUSE=static-libs - drop the PV slotting/renaming
Based on SpanKY's feedback, I cleaned up the ebuild to address all of his concerns. I also added two more use flags for bidirectional text support and for the minizip resource manager - "bidi" and minizip". One QA error message I am still getting that I do not know how to address is related to the fact that the opposite of "--enable-static" is not "--disable-static" but "--enable-shared", so if the "static-libs" USE flag is disabled, it tries to pass an invalid parameter, thus resulting in * QA Notice: command not found: * * /var/tmp/portage/dev-games/cegui-0.7.5/temp/environment: line 3006: --disable-static: command not found Otherwise it works just fine.
Created attachment 264297 [details] Updated CEGUI 0.7.5 ebuild to address QA concerns The pkgconfig patch patch is no longer needed with this ebuild.
ive dropped the freeimage stuff (it was hacky, and freeimage isnt in the tree). i also fixed up other random stuff and committed it.
(In reply to comment #26) > games-arcade/smc > which means it should be fairly easy to make sure those work with the > latest cegui, or we drop them from the tree. Cross reference: see bug #357761 about the smc breakage due to cegui update.
