libXaw3d: optional features
Is it really necessary to have libXaw3d's features not only optional but disabled by default? What is the reason for this? Yaakov Cygwin/X ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
libXaw3d: optional features
First a minor nitpick about "Use AM_YFLAGS and BUILT_SOURCES rather than EXTRA_DIST" patch: while BUILT_SOURCES is probably the correct solution there, AM_YFLAGS are redundant, it's already handled elsewhere. Now, for the question about optional features. Frankly, that part isn't really working atm, I've told so much to Matt, as I sent him those patches. That is the lib should be correctly built, but something like the sed hack that was in the original Imakefile is required, as those four defines need to record their values somewhere, so that packages that link against them get the correct values. Originally, it was done in Xaw3dP.h. IMHO, making API (and especially ABI) change depending on those values was a mistake in design, but I don't see any reasonable way to fix it. The biggest problem is obviously XAW_INTERNATIONALIZATION - the other three are in one header each and all of those are *.P.h headers. I'm not sure if it makes any difference though, as it seems at the time libXaw and libXaw3d were written there was no real separation between private and public headers. On that note, libXaw3d exports all of those LayYY* symbols - I'm not sure if it really makes sense. On the other hand, it seems libXaw does the same. Ah, the joys of legacy code. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: libXaw3d: optional features
On Sat, 2011-08-27 at 19:35 +0200, Rafał Mużyło wrote: > First a minor nitpick about "Use AM_YFLAGS and BUILT_SOURCES rather > than > EXTRA_DIST" patch: > while BUILT_SOURCES is probably the correct solution there, AM_YFLAGS > are redundant, it's already handled elsewhere. > > When not using "AM_YFLAGS = -d", laygram.h is not included in the tarball, but still generated. Building the tarball on a computer when yacc is not installed produces this error: make[1]: *** No rule to make target `laygram.h', needed by `all'. Stop. The yacc package is not required to build a tarball as the generated code is included in the said tarball, so laygram.h must be included. This target is missing in the makefile, so it does not work on a git build either. laygram.h: laygram.c @if test ! -f $@; then \ rm -f laygram.c; \ $(MAKE) $(AM_MAKEFLAGS) laygram.c; \ else :; fi Thanks for mentioning this, I had not gone to that level of details yet. signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: libXaw3d: optional features
On Sat, Aug 27, 2011 at 08:46:40PM -0400, Gaetan Nadon wrote: > On Sat, 2011-08-27 at 19:35 +0200, Rafał Mużyło wrote: > > > First a minor nitpick about "Use AM_YFLAGS and BUILT_SOURCES rather > > than > > EXTRA_DIST" patch: > > while BUILT_SOURCES is probably the correct solution there, AM_YFLAGS > > are redundant, it's already handled elsewhere. > > > > > > When not using "AM_YFLAGS = -d", laygram.h is not included in the > tarball, but still generated. Building the tarball on a computer when > yacc is not installed produces this error: > > make[1]: *** No rule to make target `laygram.h', needed by `all'. > Stop. > > The yacc package is not required to build a tarball as the generated > code is included in the said tarball, so laygram.h must be included. > > This target is missing in the makefile, so it does not work on a git > build either. > > laygram.h: laygram.c > @if test ! -f $@; then \ > rm -f laygram.c; \ > $(MAKE) $(AM_MAKEFLAGS) laygram.c; \ > else :; fi > > > Thanks for mentioning this, I had not gone to that level of details yet. So, in short AM_YFLAGS are needed mostly cause automake isn't good enough at cheating ? Cause there's already "%defines" for producing the header. It seems that putting 'BUILT_SOURCES = laygram.c' and adding laygram.h to EXTRA_DIST should work just as well, even if it seems a bit more ugly. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: libXaw3d: optional features
On Sun, 2011-08-28 at 04:04 +0200, Rafał Mużyło wrote: > On Sat, Aug 27, 2011 at 08:46:40PM -0400, Gaetan Nadon wrote: > > On Sat, 2011-08-27 at 19:35 +0200, Rafał Mużyło wrote: > > > > > First a minor nitpick about "Use AM_YFLAGS and BUILT_SOURCES rather > > > than > > > EXTRA_DIST" patch: > > > while BUILT_SOURCES is probably the correct solution there, AM_YFLAGS > > > are redundant, it's already handled elsewhere. > > > > > > > > > > When not using "AM_YFLAGS = -d", laygram.h is not included in the > > tarball, but still generated. Building the tarball on a computer when > > yacc is not installed produces this error: > > > > make[1]: *** No rule to make target `laygram.h', needed by `all'. > > Stop. > > > > The yacc package is not required to build a tarball as the generated > > code is included in the said tarball, so laygram.h must be included. > > > > This target is missing in the makefile, so it does not work on a git > > build either. > > > > laygram.h: laygram.c > > @if test ! -f $@; then \ > > rm -f laygram.c; \ > > $(MAKE) $(AM_MAKEFLAGS) laygram.c; \ > > else :; fi > > > > > > Thanks for mentioning this, I had not gone to that level of details yet. > > So, in short AM_YFLAGS are needed mostly cause automake isn't good > enough at cheating ? > Cause there's already "%defines" for producing the header. "AM_YFLAGS is usually used to pass the -d option to yacc. Automake knows what this means and will automatically adjust its rules to update and distribute the header file built by ‘yacc -d’." ./configure --help: YFLAGS The list of arguments that will be passed by default to $YACC. This script will default YFLAGS to the empty string to avoid a default value of `-d' given by some make applications. It would appear there is a long story behind this. Not to mention platforms we don't use, different versions of yacc and bison, make programs, backward compatibility, etc..., etc... There are a couple of apps and the xserver using it as well and I find it reassuring when the same situations are coded the same way and have been reviewed. Feel free to provide a review tag :-) Thanks > It seems that putting 'BUILT_SOURCES = laygram.c' and adding laygram.h > to EXTRA_DIST should work just as well, even if it seems a bit more > ugly. > > > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: libXaw3d: optional features
On Sun, Aug 28, 2011 at 10:15:05AM -0400, Gaetan Nadon wrote: > > "AM_YFLAGS is usually used to pass the -d option to yacc. > Automake knows what this means and will automatically adjust its rules > to update and distribute the header file built by ‘yacc -d’." > > > ./configure --help: > > YFLAGS The list of arguments that will be passed by default to > $YACC. > This script will default YFLAGS to the empty string to > avoid a > default value of `-d' given by some make applications. > > > It would appear there is a long story behind this. Not to mention > platforms we don't use, > different versions of yacc and bison, make programs, backward > compatibility, etc..., etc... > > There are a couple of apps and the xserver using it as well and I find > it reassuring when the same situations are coded the same way and have > been reviewed. > I can't say that I've used yacc, but 'bison -y -Wall' doesn't print any compatibility warnings about '%defines', so it should have been OK. What I really am complaining about, is automake using *only* YFLAGS for the detection, while '%defines' seems to be a valid solution too. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: libXaw3d: optional features
On Mon, 29 Aug 2011, Rafa�~B Muży�~Bo wrote: On Sun, Aug 28, 2011 at 10:15:05AM -0400, Gaetan Nadon wrote: "AM_YFLAGS is usually used to pass the -d option to yacc. Automake knows what this means and will automatically adjust its rules to update and distribute the header file built by ‘yacc -d’." ./configure --help: YFLAGS The list of arguments that will be passed by default to $YACC. This script will default YFLAGS to the empty string to avoid a default value of `-d' given by some make applications. It would appear there is a long story behind this. Not to mention platforms we don't use, different versions of yacc and bison, make programs, backward compatibility, etc..., etc... There are a couple of apps and the xserver using it as well and I find it reassuring when the same situations are coded the same way and have been reviewed. I can't say that I've used yacc, but 'bison -y -Wall' doesn't print any compatibility warnings about '%defines', so it should have been OK. It's bison-specific, as you might have discovered by checking the documention. A quick check of the source shows it was added in bison 1.29 awai -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: libXaw3d: optional features
On Mon, Aug 29, 2011 at 05:16:03AM -0400, Thomas Dickey wrote: > On Mon, 29 Aug 2011, Rafa?~B Muży?~Bo wrote: > > > I can't say that I've used yacc, but 'bison -y -Wall' doesn't print any > > compatibility warnings about '%defines', so it should have been OK. > > It's bison-specific, as you might have discovered by checking the > documention. A quick check of the source shows it was added in bison > 1.29 > If by that you've meant "google madly for any yacc docs", then probably so - the infopage doesn't seems to list at any point directives incompatible with yacc. Then again, the changes, that one of my patches made, have most likely already made those bison/flex specific. If you were to revert those, you would need to reintroduce the sed hacks original Imakefile had for LayYY prefixing. On unrelated note: your mail client seems to mangle utf8. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
