Remove framework for external modules
PATCH 1/1 Remove framework for external modules
My bad...
When I proposed adding a framework for building GRUB modules externally, I was expecting it would end up being used. I had grub-extras in mind.
But it became much simpler and straightforwarded to build grub-extras by overlaiing it into GRUB tree and doing a one-line change in GRUB Makefile.in.
So I wonder if there's anyone reliing on this. I believe there isn't, and I noticed that it's a nuissance because it installs headers in /usr/include which may later be dragged in to a newer version of GRUB, causing breakage.
So I admit having a bad idea and propose to undo it. Maintaining features is costly, we should only maintain features that are useful.
Signature · 5 lines
Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all."
2009-08-25 Robert Millan <[email protected]>
* Makefile.in (PKGLIB): Remove $(pkglib_BUILDDIR). (pkglib_BUILDDIR): Remove. (build_env.mk): Remove. (include_DATA): Remove. (install-local): Stop installing $(include_DATA) files in $(includedir).
Makefile.in +1 -40
@@ -117,7 +117,7 @@ MKFILES = $(patsubst %.rmk,%.mk,$(RMKFILES)) PKGLIB = $(pkglib_IMAGES) $(pkglib_MODULES) $(pkglib_PROGRAMS) \ - $(pkglib_DATA) $(pkglib_BUILDDIR) + $(pkglib_DATA) PKGDATA = $(pkgdata_DATA) PROGRAMS = $(bin_UTILITIES) $(sbin_UTILITIES) SCRIPTS = $(bin_SCRIPTS) $(sbin_SCRIPTS) $(grub-mkconfig_SCRIPTS) \
@@ -186,26 +186,6 @@ endif endif -# Used for building modules externally -pkglib_BUILDDIR += build_env.mk -build_env.mk: Makefile - (\ - echo "TARGET_CC=$(TARGET_CC)" ; \ - echo "TARGET_CFLAGS=$(TARGET_CFLAGS)" ; \ - echo "TARGET_ASFLAGS=$(TARGET_ASFLAGS)" ; \ - echo "TARGET_CPPFLAGS=$(TARGET_CPPFLAGS) -I$(pkglibdir) -I$(includedir)" ; \ - echo "STRIP=$(STRIP)" ; \ - echo "OBJCONV=$(OBJCONV)" ; \ - echo "TARGET_MODULE_FORMAT=$(TARGET_MODULE_FORMAT)" ; \ - echo "TARGET_APPLE_CC=$(TARGET_APPLE_CC)" ; \ - echo "COMMON_ASFLAGS=$(COMMON_ASFLAGS)" ; \ - echo "COMMON_CFLAGS=$(COMMON_CFLAGS)" ; \ - echo "COMMON_LDFLAGS=$(COMMON_LDFLAGS)"\ - ) > $@ -pkglib_BUILDDIR += config.h grub_script.tab.h -include_DATA += $(shell find $(srcdir)/include -name \*.h | sed -e "s,^$(srcdir)/,,g") \ - include/grub/cpu include/grub/machine - all-local: $(PROGRAMS) $(PKGLIB) $(PKGDATA) $(SCRIPTS) $(MKFILES) install: install-local
@@ -219,20 +199,6 @@ dest="`echo $$file | sed 's,.*/,,'`"; \ $(INSTALL_DATA) $$dir$$file $(DESTDIR)$(pkglibdir)/$$dest; \ done - $(SHELL) $(mkinstalldirs) $(DESTDIR)$(includedir) - @list='$(include_DATA)'; \ - for file in $$list; do \ - if test -e "$$file"; then dir=; else dir="$(srcdir)/"; fi; \ - dest="`echo $$file | sed 's,include/,,'`"; \ - destdir="`echo $$dest | sed 's,[^/]*$$,,g'`"; \ - $(SHELL) $(mkinstalldirs) $(DESTDIR)$(includedir)/$$destdir; \ - if test -f "$$dir$$file"; then \ - $(INSTALL_DATA) $$dir$$file $(DESTDIR)$(includedir)/$$dest; \ - elif test -L "$$dir$$file"; then \ - rm -rf $(DESTDIR)$(includedir)/$$dest && \ - cp -fR $$dir$$file $(DESTDIR)$(includedir)/$$dest; \ - fi; \ - done $(SHELL) $(mkinstalldirs) $(DESTDIR)$(pkgdatadir) @list='$(PKGDATA)'; \ for file in $$list; do \
@@ -313,11 +279,6 @@ dest="`echo $$file | sed 's,.*/,,' | sed '$(transform)'`"; \ rm -f $(DESTDIR)$(sysconfdir)/grub.d/$$dest; \ done - @list='$(include_DATA)'; \ - for file in $$list; do \ - dest="`echo $$file | sed 's,include/,,'`"; \ - rm -f $(DESTDIR)$(includedir)/$$dest; \ - done @list='$(lib_SCRIPTS)'; \ for file in $$list; do \ dest="`echo $$file | sed 's,.*/,,'`"; \
Quoted 10 lines · Robert Millan
My bad...
When I proposed adding a framework for building GRUB modules externally, I was expecting it would end up being used. I had grub-extras in mind.
But it became much simpler and straightforwarded to build grub-extras by overlaiing it into GRUB tree and doing a one-line change in GRUB Makefile.in.
So I wonder if there's anyone reliing on this. I believe there isn't, and I
I'm using it.
I am (my employer is) writing a set of modules to make grub do something it doesn't do yet. My employer prefers that I not discuss details at this time.
I really like keeping the module code completely separate from the common grub code. If the external build stuff goes away, I can work around it, but it's not preferred.
Quoted 2 lines
noticed that it's a nuissance because it installs headers in
/usr/includewhich may later be dragged in to a newer version of GRUB, causing breakage.
I don't need headers in /usr/include. In fact I am happy with an -I flag pointing to the grub source dir. I vote we stop installing the headers.
Quoted 2 lines
So I admit having a bad idea and propose to undo it. Maintaining features is costly, we should only maintain features that are useful.
I understand this and I agree completely. But it doesn't seem to cost us anything *right now* to keep build_env.mk and the 'idea' of external modules. Can we leave this code alone until a real problem appears? I don't think it's hurting anyone right now?
-joe
(footnote) We are applying GPL license to these modules, but they'll never end up in the grub tree. Our requirements are too weird. You won't want to merge this code, believe me.
Quoted 30 lines · Joe Auricchio
Quoted 10 lines · Robert Millan
My bad...
When I proposed adding a framework for building GRUB modules externally, I was expecting it would end up being used. I had grub-extras in mind.
But it became much simpler and straightforwarded to build grub-extras by overlaiing it into GRUB tree and doing a one-line change in GRUB Makefile.in.
So I wonder if there's anyone reliing on this. I believe there isn't, and I
I'm using it.
I am (my employer is) writing a set of modules to make grub do something it doesn't do yet. My employer prefers that I not discuss details at this time.
I really like keeping the module code completely separate from the common grub code. If the external build stuff goes away, I can work around it, but it's not preferred.
Quoted 2 lines
noticed that it's a nuissance because it installs headers in
/usr/includewhich may later be dragged in to a newer version of GRUB, causing breakage.I don't need headers in
/usr/include. In fact I am happy with an -I flag pointing to the grub source dir. I vote we stop installing the headers.
Quoted 7 lines
Quoted 2 lines
So I admit having a bad idea and propose to undo it. Maintaining features is costly, we should only maintain features that are useful.
I understand this and I agree completely. But it doesn't seem to cost us anything *right now* to keep build_env.mk and the 'idea' of external modules. Can we leave this code alone until a real problem appears? I don't think it's hurting anyone right now?
Only the headers are problematic.
As for the rest, I suggest you look at how grub-extras does this now, but if you still need this I don't mind keeping it around.
Do you mind if we stop installing headers then?
Quoted 3 lines
(footnote) We are applying GPL license to these modules, but they'll never end up in the grub tree. Our requirements are too weird. You won't want to merge this code, believe me.
I understand. Good luck with it!
Signature · 5 lines
Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all."
Quoted 5 lines
Quoted 3 lines
(footnote) We are applying GPL license to these modules, but they'll never end up in the grub tree. Our requirements are too weird. You won't want to merge this code, believe me.
I understand. Good luck with it!
This case is exactly something external module build want to prevent. If it wasn't available people wanting weird thing would be likely to end up with a badly maintained unsynced own fork. In turn this fork is likely to cause repeat of old bug reports on savannah. (I know posting fork bugs to savannah isn't appropriate but we have inapropriate bug reports even now (e.g. bugs in debian build system))
Quoted 14 lines
--
Robert MillanThe DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all."
_______________________________________________
Grub-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/grub-devel
Signature · 4 lines
Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
Quoted 39 lines · Robert Millan
Quoted 30 lines · Joe Auricchio
Quoted 10 lines · Robert Millan
My bad...
When I proposed adding a framework for building GRUB modules externally, I was expecting it would end up being used. I had grub-extras in mind.
But it became much simpler and straightforwarded to build grub-extras by overlaiing it into GRUB tree and doing a one-line change in GRUB Makefile.in.
So I wonder if there's anyone reliing on this. I believe there isn't, and I
I'm using it.
I am (my employer is) writing a set of modules to make grub do something it doesn't do yet. My employer prefers that I not discuss details at this time.
I really like keeping the module code completely separate from the common grub code. If the external build stuff goes away, I can work around it, but it's not preferred.
Quoted 2 lines
noticed that it's a nuissance because it installs headers in
/usr/includewhich may later be dragged in to a newer version of GRUB, causing breakage.I don't need headers in
/usr/include. In fact I am happy with an -I flag pointing to the grub source dir. I vote we stop installing the headers.Quoted 7 lines
Quoted 2 lines
So I admit having a bad idea and propose to undo it. Maintaining features is costly, we should only maintain features that are useful.
I understand this and I agree completely. But it doesn't seem to cost us anything *right now* to keep build_env.mk and the 'idea' of external modules. Can we leave this code alone until a real problem appears? I don't think it's hurting anyone right now?
Quoted 7 lines
Only the headers are problematic.
As for the rest, I suggest you look at how grub-extras does this now, but if you still need this I don't mind keeping it around.
Do you mind if we stop installing headers then?
What about installing headers in a non-standard directory? And what do we do with multiboot.h and multiboot2.h?
Quoted 19 lines
Quoted 3 lines
(footnote) We are applying GPL license to these modules, but they'll never end up in the grub tree. Our requirements are too weird. You won't want to merge this code, believe me.
I understand. Good luck with it!
--
Robert MillanThe DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all."
_______________________________________________
Grub-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/grub-devel
Signature · 4 lines
Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
Quoted 11 lines · Vladimir 'phcoder' Serbinenko
Quoted 5 lines
Quoted 3 lines
(footnote) We are applying GPL license to these modules, but they'll never end up in the grub tree. Our requirements are too weird. You won't want to merge this code, believe me.
I understand. Good luck with it!
This case is exactly something external module build want to prevent. If it wasn't available people wanting weird thing would be likely to end up with a badly maintained unsynced own fork. In turn this fork is likely to cause repeat of old bug reports on savannah. (I know posting fork bugs to savannah isn't appropriate but we have inapropriate bug reports even now (e.g. bugs in debian build system))
This is not a fork. Private modifications are very common in the free software world, specially in corporate environments which tend to have very specific requisites.
The only question is whether we should take extra steps to make these modifications easier.
Signature · 5 lines
Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all."