On Tue, Aug 25, 2009 at 14:13, Robert Millan<r...@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. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
