Message ID | 20101125202820.a2aff938.basile@starynkevitch.net |
---|---|
State | New |
Headers | show |
On Thu, 25 Nov 2010 20:28:20 +0100 Basile Starynkevitch <basile@starynkevitch.net> wrote: > Now that gengtype has been improved for plugins, it becomes a user > visible program (for those brave users coding plugins) we need to install it. In addition, we might need a testcase for gengtype, since it is a user program, and we can now test it in plugin mode. However, I am not familiar enough with dejagnu to propose one. Could someone help please? What should be the form of a testcase for gengtype in plugin mode? I would imagine that we could run it in plugin mode on a tiny plugin.c containing some GTY, and request the resulting generated gt-plugin.h to contain so expected regular expression (or just some expected words) but I don't know how to code that. Besides, such a testcase example would be useful when adding new features into gengtype. For instance (but I don't say I want to do that), adding support for C++ GTY-ed types should very probably first be tested for plugins, and only later could we accept GTY-ing C++ code in the core of GCC. Cheers. PS. Is gcc-patches@ the right list to ask for help on dejagnu code I am not able to write?
On Thu, 25 Nov 2010, Basile Starynkevitch wrote: > +# Additional build executables to be installed. > +ADDITIONAL_BUILD_PROGRAMS= build/gengtype$(build_exeext) It is definitely wrong to install anything built for the build system. Anything installed in libexecsubdir should be built for the host, not the build system.
On Thu, 25 Nov 2010 22:20:40 +0000 (UTC) "Joseph S. Myers" <joseph@codesourcery.com> wrote: > On Thu, 25 Nov 2010, Basile Starynkevitch wrote: > > > +# Additional build executables to be installed. > > +ADDITIONAL_BUILD_PROGRAMS= build/gengtype$(build_exeext) > > It is definitely wrong to install anything built for the build system. > Anything installed in libexecsubdir should be built for the host, not the > build system. Ok, but what do you suggest instead? At least in the usual straight (= non cross-compiler) case, gengtype is becoming a user visible program of GCC, since users coding plugins need it. How and how should it be installed, at least in that case?
On Fri, 26 Nov 2010 00:38:12 +0100 Basile Starynkevitch <basile@starynkevitch.net> wrote: > > At least in the usual straight (= non cross-compiler) case, gengtype is becoming a user visible program of GCC, since users coding plugins need it. > > How and how should it be installed, at least in that case? Sorry, I mean How and whee should it be installed, at least in that case? Cheers
On Fri, 26 Nov 2010, Basile Starynkevitch wrote: > On Thu, 25 Nov 2010 22:20:40 +0000 (UTC) > "Joseph S. Myers" <joseph@codesourcery.com> wrote: > > > On Thu, 25 Nov 2010, Basile Starynkevitch wrote: > > > > > +# Additional build executables to be installed. > > > +ADDITIONAL_BUILD_PROGRAMS= build/gengtype$(build_exeext) > > > > It is definitely wrong to install anything built for the build system. > > Anything installed in libexecsubdir should be built for the host, not the > > build system. > > Ok, but what do you suggest instead? If you wish to install gengtype, you must build it twice, for both the build and host systems, use the build-system copy as part of the build process but install the host-system copy. This is just like what is done with fixincludes: the build-system copy is used in the build process but the host-system copy is installed for potential later use in regenerating fixed headers after changes in system headers.
On Fri, 26 Nov 2010 00:18:09 +0000 (UTC) "Joseph S. Myers" <joseph@codesourcery.com> wrote: > If you wish to install gengtype, you must build it twice, for both the > build and host systems, use the build-system copy as part of the build > process but install the host-system copy. This is just like what is done > with fixincludes: the build-system copy is used in the build process but > the host-system copy is installed for potential later use in regenerating > fixed headers after changes in system headers. Are you suggesting to install gengtype under $(libexecsubdir)/install-tools as in fixincludes/Makefile.in? Or where? Cheers
On Fri, 26 Nov 2010, Basile Starynkevitch wrote: > On Fri, 26 Nov 2010 00:18:09 +0000 (UTC) > "Joseph S. Myers" <joseph@codesourcery.com> wrote: > > If you wish to install gengtype, you must build it twice, for both the > > build and host systems, use the build-system copy as part of the build > > process but install the host-system copy. This is just like what is done > > with fixincludes: the build-system copy is used in the build process but > > the host-system copy is installed for potential later use in regenerating > > fixed headers after changes in system headers. > > Are you suggesting to install gengtype under $(libexecsubdir)/install-tools > as in fixincludes/Makefile.in? plugin-tools would be a better name than install-tools.
2010/11/25 Basile Starynkevitch <basile@starynkevitch.net>: > What should be the form of a testcase for gengtype in plugin mode? > I would imagine that we could run it in plugin mode on a tiny plugin.c > containing some GTY, and request the resulting generated gt-plugin.h to > contain so expected regular expression (or just some expected words) > but I don't know how to code that. Or have some little source file that includes gt-plugin.h and fails to compile if any of the expected symbols are undefined. I am not familiar with dejagnu, so I cannot offer further advice.
Hello Basile, * Basile Starynkevitch wrote on Thu, Nov 25, 2010 at 08:28:20PM CET: > There is also a typo (suscpiscous tab character detected by Emacs near line 3735) > --- gcc/Makefile.in (revision 167150) > +++ gcc/Makefile.in (working copy) > @@ -3731,7 +3735,7 @@ s-tm-texi: build/genhooks$(build_exeext) $(srcdir) > $(srcdir)/doc/tm.texi.in > tmp-tm.texi > case `echo X|tr X '\101'` in \ > A) tr -d '\015' < tmp-tm.texi > tmp2-tm.texi ;; \ > - *) tr -d '\r' < tmp-tm.texi > tmp2-tm.texi ;; \ > + *) tr -d '\r' < tmp-tm.texi > tmp2-tm.texi ;; \ > esac > mv tmp2-tm.texi tmp-tm.texi > $(SHELL) $(srcdir)/../move-if-change tmp-tm.texi tm.texi Such changes are better installed as a separate patch, and are obvious to apply. Thanks, Ralf
On Fri, 26 Nov 2010 07:50:54 +0100 Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote: > Hello Basile, > > * Basile Starynkevitch wrote on Thu, Nov 25, 2010 at 08:28:20PM CET: > > There is also a typo (suscpiscous tab character detected by Emacs near line 3735) > > > --- gcc/Makefile.in (revision 167150) > > +++ gcc/Makefile.in (working copy) > > > @@ -3731,7 +3735,7 @@ s-tm-texi: build/genhooks$(build_exeext) $(srcdir) > > $(srcdir)/doc/tm.texi.in > tmp-tm.texi > > case `echo X|tr X '\101'` in \ > > A) tr -d '\015' < tmp-tm.texi > tmp2-tm.texi ;; \ > > - *) tr -d '\r' < tmp-tm.texi > tmp2-tm.texi ;; \ > > + *) tr -d '\r' < tmp-tm.texi > tmp2-tm.texi ;; \ > > esac > > mv tmp2-tm.texi tmp-tm.texi > > $(SHELL) $(srcdir)/../move-if-change tmp-tm.texi tm.texi > > Such changes are better installed as a separate patch, and are obvious > to apply. I understood that as a Ok and svn Committed revision 167167 [changing a tab to a space] with the following gcc/ChangeLog entry 2010-11-26 Basile Starynkevitch <basile@starynkevitch.net> * Makefile.in (s-tm-texi): Remove spurous tab. Back to gengtype, to Ralf & Alexander and others, do you have some concrete patch ideas about how to install gengtype? I am confused, and my understanding of GCC build procedure is quite weak in the details... What should we do to have gengtype installed as a user visible program (for those few users wanting to develop plugins with GTY-s)?? How should we install it? Where? Cheers
On Fri, 26 Nov 2010 02:33:56 +0000 (UTC) "Joseph S. Myers" <joseph@codesourcery.com> wrote: > On Fri, 26 Nov 2010, Basile Starynkevitch wrote: > > > On Fri, 26 Nov 2010 00:18:09 +0000 (UTC) > > "Joseph S. Myers" <joseph@codesourcery.com> wrote: > > > If you wish to install gengtype, you must build it twice, for both the > > > build and host systems, use the build-system copy as part of the build > > > process but install the host-system copy. This is just like what is done > > > with fixincludes: the build-system copy is used in the build process but > > > the host-system copy is installed for potential later use in regenerating > > > fixed headers after changes in system headers. > > > > Are you suggesting to install gengtype under $(libexecsubdir)/install-tools > > as in fixincludes/Makefile.in? > > plugin-tools would be a better name than install-tools. I am not able to propose a patch which install gengtype (& gtype.state) appropriately. I just opened PR 46828 to get some help. Sorry ladies & gentlemen, I am not able to work out that alone (and I still guess that for people understanding GCC build machinery, it is a very small patch). Cheers.
Index: gcc/Makefile.in =================================================================== --- gcc/Makefile.in (revision 167150) +++ gcc/Makefile.in (working copy) @@ -681,6 +681,10 @@ SHLIBUNWIND_INSTALL = # nm flags to list global symbols in libgcc object files. SHLIB_NM_FLAGS = -pg + +# Additional build executables to be installed. +ADDITIONAL_BUILD_PROGRAMS= build/gengtype$(build_exeext) + # List of extra executables that should be compiled for this target machine # that are used for compiling from source code to object code. # The rules for compiling them should be in the t-* file for the machine. @@ -3731,7 +3735,7 @@ s-tm-texi: build/genhooks$(build_exeext) $(srcdir) $(srcdir)/doc/tm.texi.in > tmp-tm.texi case `echo X|tr X '\101'` in \ A) tr -d '\015' < tmp-tm.texi > tmp2-tm.texi ;; \ - *) tr -d '\r' < tmp-tm.texi > tmp2-tm.texi ;; \ + *) tr -d '\r' < tmp-tm.texi > tmp2-tm.texi ;; \ esac mv tmp2-tm.texi tmp-tm.texi $(SHELL) $(srcdir)/../move-if-change tmp-tm.texi tm.texi @@ -4610,10 +4614,11 @@ install-common: native lang.install-common install else true; \ fi; \ done - for file in $(EXTRA_PASSES) $(EXTRA_PROGRAMS) $(COLLECT2) ..; do \ + for file in $(EXTRA_PASSES) $(EXTRA_PROGRAMS) \ + $(ADDITIONAL_BUILD_PROGRAMS) $(COLLECT2) ..; do \ if [ x"$$file" != x.. ]; then \ - rm -f $(DESTDIR)$(libexecsubdir)/$$file; \ - $(INSTALL_PROGRAM) $$file $(DESTDIR)$(libexecsubdir)/$$file; \ + rm -f $(DESTDIR)$(libexecsubdir)/$(notdir $$file); \ + $(INSTALL_PROGRAM) $$file $(DESTDIR)$(libexecsubdir)/$(notdir $$file); \ else true; fi; \ done # We no longer install the specs file because its presence makes the