diff mbox

[libffi] do not install libffi library, headers and documentation

Message ID 51225EBE.1050509@ubuntu.com
State New
Headers show

Commit Message

Matthias Klose Feb. 18, 2013, 5:02 p.m. UTC
Am 12.02.2013 13:45, schrieb Richard Biener:
> On Tue, Feb 12, 2013 at 1:44 PM, Richard Biener
> <richard.guenther@gmail.com> wrote:
>> On Tue, Feb 12, 2013 at 1:30 PM, Matthias Klose <doko@ubuntu.com> wrote:
>>> The libffi library, headers and documentation are still installed, although
>>> libffi provides separate releases for a long time.  So do not install these
>>> anymore as part of a GCC install.  Tested with a build and an install with go
>>> and java enabled (both using libffi_convenience). Ok for the trunk?
>>
>> openSUSE is using the GCC provided libffi, so no, this is not ok (not at this
>> stage anyway).  Also proper not-installing libffi would work by disabling
>> the maybe-install-target-libffi at the toplevel, not changing libffi makfiles
>> (which are supposed to be imported from upstream, no?)
> 
> Thus, add no_install= true; to the libffi target module

updated patch attached, checked with a make install that no ffi headers and
libraries are installed. If not ok for 4.8, ok for 4.9 when it opens?

  Matthias

Comments

Richard Biener Feb. 19, 2013, 9:13 a.m. UTC | #1
On Mon, Feb 18, 2013 at 6:02 PM, Matthias Klose <doko@ubuntu.com> wrote:
> Am 12.02.2013 13:45, schrieb Richard Biener:
>> On Tue, Feb 12, 2013 at 1:44 PM, Richard Biener
>> <richard.guenther@gmail.com> wrote:
>>> On Tue, Feb 12, 2013 at 1:30 PM, Matthias Klose <doko@ubuntu.com> wrote:
>>>> The libffi library, headers and documentation are still installed, although
>>>> libffi provides separate releases for a long time.  So do not install these
>>>> anymore as part of a GCC install.  Tested with a build and an install with go
>>>> and java enabled (both using libffi_convenience). Ok for the trunk?
>>>
>>> openSUSE is using the GCC provided libffi, so no, this is not ok (not at this
>>> stage anyway).  Also proper not-installing libffi would work by disabling
>>> the maybe-install-target-libffi at the toplevel, not changing libffi makfiles
>>> (which are supposed to be imported from upstream, no?)
>>
>> Thus, add no_install= true; to the libffi target module
>
> updated patch attached, checked with a make install that no ffi headers and
> libraries are installed. If not ok for 4.8, ok for 4.9 when it opens?

I'm fine with that variant but I'd like to see another ok.  No preference as to
whether to target 4.8 or 4.9.

Richard.

>   Matthias
>
Matthias Klose March 26, 2013, 8:03 p.m. UTC | #2
[ping, adding the GCJ and Go maintainers]

proposed patch at http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00853.html

Am 19.02.2013 10:13, schrieb Richard Biener:
> On Mon, Feb 18, 2013 at 6:02 PM, Matthias Klose <doko@ubuntu.com> wrote:
>> Am 12.02.2013 13:45, schrieb Richard Biener:
>>> On Tue, Feb 12, 2013 at 1:44 PM, Richard Biener
>>> <richard.guenther@gmail.com> wrote:
>>>> On Tue, Feb 12, 2013 at 1:30 PM, Matthias Klose <doko@ubuntu.com> wrote:
>>>>> The libffi library, headers and documentation are still installed, although
>>>>> libffi provides separate releases for a long time.  So do not install these
>>>>> anymore as part of a GCC install.  Tested with a build and an install with go
>>>>> and java enabled (both using libffi_convenience). Ok for the trunk?
>>>>
>>>> openSUSE is using the GCC provided libffi, so no, this is not ok (not at this
>>>> stage anyway).  Also proper not-installing libffi would work by disabling
>>>> the maybe-install-target-libffi at the toplevel, not changing libffi makfiles
>>>> (which are supposed to be imported from upstream, no?)
>>>
>>> Thus, add no_install= true; to the libffi target module
>>
>> updated patch attached, checked with a make install that no ffi headers and
>> libraries are installed. If not ok for 4.8, ok for 4.9 when it opens?
> 
> I'm fine with that variant but I'd like to see another ok.  No preference as to
> whether to target 4.8 or 4.9.
> 
> Richard.
> 
>>   Matthias
>>
Ian Lance Taylor March 26, 2013, 8:28 p.m. UTC | #3
On Tue, Mar 26, 2013 at 1:03 PM, Matthias Klose <doko@ubuntu.com> wrote:
> [ping, adding the GCJ and Go maintainers]
>
> proposed patch at http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00853.html

As far as I know this won't affect Go.  So it's fine with me.  But I'd
rather see this approved by a libffi maintainer.  But there is no
libffi maintainer listed in MAINTAINERS.  Hmmm.

Ian


> Am 19.02.2013 10:13, schrieb Richard Biener:
>> On Mon, Feb 18, 2013 at 6:02 PM, Matthias Klose <doko@ubuntu.com> wrote:
>>> Am 12.02.2013 13:45, schrieb Richard Biener:
>>>> On Tue, Feb 12, 2013 at 1:44 PM, Richard Biener
>>>> <richard.guenther@gmail.com> wrote:
>>>>> On Tue, Feb 12, 2013 at 1:30 PM, Matthias Klose <doko@ubuntu.com> wrote:
>>>>>> The libffi library, headers and documentation are still installed, although
>>>>>> libffi provides separate releases for a long time.  So do not install these
>>>>>> anymore as part of a GCC install.  Tested with a build and an install with go
>>>>>> and java enabled (both using libffi_convenience). Ok for the trunk?
>>>>>
>>>>> openSUSE is using the GCC provided libffi, so no, this is not ok (not at this
>>>>> stage anyway).  Also proper not-installing libffi would work by disabling
>>>>> the maybe-install-target-libffi at the toplevel, not changing libffi makfiles
>>>>> (which are supposed to be imported from upstream, no?)
>>>>
>>>> Thus, add no_install= true; to the libffi target module
>>>
>>> updated patch attached, checked with a make install that no ffi headers and
>>> libraries are installed. If not ok for 4.8, ok for 4.9 when it opens?
>>
>> I'm fine with that variant but I'd like to see another ok.  No preference as to
>> whether to target 4.8 or 4.9.
>>
>> Richard.
>>
>>>   Matthias
>>>
>
Anthony Green March 26, 2013, 8:48 p.m. UTC | #4
For what it's worth, this patch is fine by me.  I had originally
proposed that GCC not install these bits.

As far as maintainers go, I thought that I was once listed in the
MAINTAINERS file.  Feel free to add Andrew Haley and/or myself.

Thanks,

Anthony Green

On Tue, Mar 26, 2013 at 4:28 PM, Ian Lance Taylor <iant@google.com> wrote:
> On Tue, Mar 26, 2013 at 1:03 PM, Matthias Klose <doko@ubuntu.com> wrote:
>> [ping, adding the GCJ and Go maintainers]
>>
>> proposed patch at http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00853.html
>
> As far as I know this won't affect Go.  So it's fine with me.  But I'd
> rather see this approved by a libffi maintainer.  But there is no
> libffi maintainer listed in MAINTAINERS.  Hmmm.
>
> Ian
>
>
>> Am 19.02.2013 10:13, schrieb Richard Biener:
>>> On Mon, Feb 18, 2013 at 6:02 PM, Matthias Klose <doko@ubuntu.com> wrote:
>>>> Am 12.02.2013 13:45, schrieb Richard Biener:
>>>>> On Tue, Feb 12, 2013 at 1:44 PM, Richard Biener
>>>>> <richard.guenther@gmail.com> wrote:
>>>>>> On Tue, Feb 12, 2013 at 1:30 PM, Matthias Klose <doko@ubuntu.com> wrote:
>>>>>>> The libffi library, headers and documentation are still installed, although
>>>>>>> libffi provides separate releases for a long time.  So do not install these
>>>>>>> anymore as part of a GCC install.  Tested with a build and an install with go
>>>>>>> and java enabled (both using libffi_convenience). Ok for the trunk?
>>>>>>
>>>>>> openSUSE is using the GCC provided libffi, so no, this is not ok (not at this
>>>>>> stage anyway).  Also proper not-installing libffi would work by disabling
>>>>>> the maybe-install-target-libffi at the toplevel, not changing libffi makfiles
>>>>>> (which are supposed to be imported from upstream, no?)
>>>>>
>>>>> Thus, add no_install= true; to the libffi target module
>>>>
>>>> updated patch attached, checked with a make install that no ffi headers and
>>>> libraries are installed. If not ok for 4.8, ok for 4.9 when it opens?
>>>
>>> I'm fine with that variant but I'd like to see another ok.  No preference as to
>>> whether to target 4.8 or 4.9.
>>>
>>> Richard.
>>>
>>>>   Matthias
>>>>
>>
Matthias Klose March 30, 2013, 11:26 a.m. UTC | #5
Am 26.03.2013 21:48, schrieb Anthony Green:
> For what it's worth, this patch is fine by me.  I had originally
> proposed that GCC not install these bits.

now applied on trunk and the 4.8 branch.

> As far as maintainers go, I thought that I was once listed in the
> MAINTAINERS file.  Feel free to add Andrew Haley and/or myself.

I didn't hear back form Andrew.  Could you do this yourself, maybe updating
libffi on trunk to the 3.0.13 release? ;)

  Matthias
diff mbox

Patch


	* Makefile.def (target_modules): Don't install libffi.
	* Makefile.in: Regenerate.

Index: Makefile.def
===================================================================
--- Makefile.def	(Revision 196115)
+++ Makefile.def	(Arbeitskopie)
@@ -138,7 +138,7 @@ 
                    missing=maintainer-clean; };
 target_modules = { module= winsup; };
 target_modules = { module= libgloss; no_check=true; };
-target_modules = { module= libffi; };
+target_modules = { module= libffi; no_install=true; };
 target_modules = { module= libjava; raw_cxx=true;
                    extra_configure_flags="$(EXTRA_CONFIGARGS_LIBJAVA)"; };
 target_modules = { module= zlib; };
Index: Makefile.in
===================================================================
--- Makefile.in	(Revision 196115)
+++ Makefile.in	(Arbeitskopie)
@@ -38710,13 +38710,8 @@ 
 @if target-libffi
 maybe-install-target-libffi: install-target-libffi
 
-install-target-libffi: installdirs
-	@: $(MAKE); $(unstage)
-	@r=`${PWD_COMMAND}`; export r; \
-	s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
-	$(NORMAL_TARGET_EXPORTS) \
-	(cd $(TARGET_SUBDIR)/libffi && \
-	  $(MAKE) $(TARGET_FLAGS_TO_PASS)  install)
+# Dummy target for uninstallable.
+install-target-libffi:
 
 @endif target-libffi
 
@@ -38725,13 +38720,8 @@ 
 @if target-libffi
 maybe-install-strip-target-libffi: install-strip-target-libffi
 
-install-strip-target-libffi: installdirs
-	@: $(MAKE); $(unstage)
-	@r=`${PWD_COMMAND}`; export r; \
-	s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
-	$(NORMAL_TARGET_EXPORTS) \
-	(cd $(TARGET_SUBDIR)/libffi && \
-	  $(MAKE) $(TARGET_FLAGS_TO_PASS)  install-strip)
+# Dummy target for uninstallable.
+install-strip-target-libffi:
 
 @endif target-libffi