[PATCH] Remove framework for external modules

[PATCH] Remove framework for external modules

[Robert Millan]

[-- Attachment #1: Type: text/plain, Size: 911 bytes --]


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.

-- 
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."

[-- Attachment #2: remove_external_module_framework.diff --]
[-- Type: text/x-diff, Size: 2905 bytes --]

2009-08-25  Robert Millan  <rmh@aybabtu.com>

	* 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).

Index: Makefile.in
===================================================================
--- Makefile.in	(revision 2531)
+++ Makefile.in	(working copy)
@@ -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,.*/,,'`"; \

Re: [PATCH] Remove framework for external modules

[Joe Auricchio]

On Tue, Aug 25, 2009 at 14:13, Robert Millan<rmh@aybabtu.com> wrote:
>
> 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.


> 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.

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.

> 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.

Re: [PATCH] Remove framework for external modules

[Robert Millan]

On Wed, Aug 26, 2009 at 09:20:58PM -0700, Joe Auricchio wrote:
> On Tue, Aug 25, 2009 at 14:13, Robert Millan<rmh@aybabtu.com> wrote:
> >
> > 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.
> 
> 
> > 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.
> 
> 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.
> 
> > 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?

> (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 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."

Re: [PATCH] Remove framework for external modules

[Vladimir 'phcoder' Serbinenko]

>> (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))
>
> --
> 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."
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: [PATCH] Remove framework for external modules

[Vladimir 'phcoder' Serbinenko]

On Fri, Aug 28, 2009 at 2:48 PM, Robert Millan<rmh@aybabtu.com> wrote:
> On Wed, Aug 26, 2009 at 09:20:58PM -0700, Joe Auricchio wrote:
>> On Tue, Aug 25, 2009 at 14:13, Robert Millan<rmh@aybabtu.com> wrote:
>> >
>> > 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.
>>
>>
>> > 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.
>>
>> 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.
>>
>> > 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?
>
What about installing headers in a non-standard directory? And what do
we do with multiboot.h and multiboot2.h?
>> (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 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."
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: [PATCH] Remove framework for external modules

[Robert Millan]

On Fri, Aug 28, 2009 at 04:04:39PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> >> (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.

-- 
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."