With 1.6.1 (perhaps 1.6), Xaw3d no longer puts the following defines in Xaw3d/Xaw3dP.h: #define XAW_INTERNATIONALIZATION #define XAW_MULTIPLANE_PIXMAPS #define XAW_GRAY_BLKWHT_STIPPLES #define XAW_ARROW_SCROLLBARS But instead puts them in the xaw3d pkg-config file. I'd like to know why this was done as it seems likely to break code that uses Xaw3d and setting these defines appears to be mandatory, not optional. Not setting them when compiling gv against Xaw3d causes gv to crash.
It looks like I lost this when I converted from imake -> autotools. It wasn't intentional, but do we actually want these #defines in an installed header? It seems like the kind of thing we'd do before we had pkgconfig.
If they were purely optional defines I would say yes. But these appear to affect the API/ABI of Xaw3d and if so it really should be in the API (headers). But I am by no means an expert here.
Hi, I'm one of the Fedora Xaw3d maintainers. So my 2 cents on this are: If some configure flags result in ABI changes, and those ABI changes are mode visible to using apps through #ifdef magic in the public headers, then the necessary defines should be part of the headers and not of pkg-config --cflags, so that things will work for non pkg-config-ified apps too. This is esp. true for a library as old as Xaw3d which likely has many users not using pkg-config. So the configure script should automatically put the necessary defines in a header file included by all other header files (similar to the config.h file, but please don't use config.h as that tends includes lot of generic defines which will cause namespace conflicts). Regards, Hans
(In reply to comment #1) > It looks like I lost this when I converted from imake -> autotools. It wasn't > intentional, but do we actually want these #defines in an installed header? It > seems like the kind of thing we'd do before we had pkgconfig. Yes. but since we have only had pkgconfig support for Xaw3d for a couple months, we can't count on the previous 15 years of applications using it yet, so putting the defines in a header for a transition period will allow distros to package it without getting all the clients updated at the same time. If this was a brand new library, then going pkgconfig only would work, but hopefully no one ever creates a brand new Xaw fork again.
I agree that they should be in the public .h. The src/README.XAW3D even documents it as such: Xaw3dP.h contains four definitions that may be used for this purpose. For example: #define XAW_INTERNATIONALIZATION #define XAW_MULTIPLANE_PIXMAPS #define XAW_GRAY_BLKWHT_STIPPLES #undef XAW_ARROW_SCROLLBARS Xaw3dP.h need not be included by the application source, as the public headers that reference any 3D features include this header. It's also a good idea to make things as easy as possible for downstream users, keeping libxaw3d as self-contained as possible (why rely on xaw3d.pc telling user to do something to tell libxaw3d to do what it is ABI-coded to do, vs that feedback loop getting broken and breaking API vs ABI?). It would be easy enough to distribute Xaw3dP.h.in that has tokens replaced by configure.ac directives to generate a hard-coded locally-correct Xaw3dP.h at build-time.
Aw heck, even Xaw3dP.h still has the placeholders and documentation for setting the API tokens. But anyway, I whipped up a patch that Works For Me(tm). See: http://lists.x.org/archives/xorg-devel/2012-August/033188.html
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/lib/libxaw3d/issues/1.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.