diff mbox

gengtype plugin improvement last4round -patch 7 [install]

Message ID 20101125202820.a2aff938.basile@starynkevitch.net
State New
Headers show

Commit Message

Basile Starynkevitch Nov. 25, 2010, 7:28 p.m. UTC
Hello All,

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.
As Alexander Oliva told me at the GCC summit, we can install it at the
same place as cc1.

There is also a typo (suscpiscous tab character detected by Emacs near line 3735)

############## patch to trunk 167150
################### gcc/ChangeLog entry
2010-11-25  Basile Starynkevitch  <basile@starynkevitch.net>
	* Makefile.in (ADDITIONAL_BUILD_PROGRAMS): New variable.
	(install-common): Also install $(ADDITIONAL_BUILD_PROGRAMS) and 
        use $(notdir).
################### 

Ok for trunk with what changes?

Cheers

Comments

Basile Starynkevitch Nov. 25, 2010, 7:39 p.m. UTC | #1
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?
Joseph Myers Nov. 25, 2010, 10:20 p.m. UTC | #2
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.
Basile Starynkevitch Nov. 25, 2010, 11:38 p.m. UTC | #3
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?
Basile Starynkevitch Nov. 25, 2010, 11:41 p.m. UTC | #4
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
Joseph Myers Nov. 26, 2010, 12:18 a.m. UTC | #5
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.
Basile Starynkevitch Nov. 26, 2010, 12:43 a.m. UTC | #6
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
Joseph Myers Nov. 26, 2010, 2:33 a.m. UTC | #7
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.
Laurynas Biveinis Nov. 26, 2010, 3:11 a.m. UTC | #8
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.
Ralf Wildenhues Nov. 26, 2010, 6:50 a.m. UTC | #9
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
Basile Starynkevitch Nov. 26, 2010, 7:18 a.m. UTC | #10
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
Basile Starynkevitch Dec. 6, 2010, 8:50 p.m. UTC | #11
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.
diff mbox

Patch

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