* Linking
@ 2008-07-25 5:17 Viswesh S
2008-07-25 5:35 ` Linking Pavel Roskin
2008-07-25 15:18 ` Remove conf/*.mk from svn (was: Re: Linking) Colin D Bennett
0 siblings, 2 replies; 17+ messages in thread
From: Viswesh S @ 2008-07-25 5:17 UTC (permalink / raw)
To: grub-devel
[-- Attachment #1: Type: text/plain, Size: 3708 bytes --]
Hi,
I am quite new to grub2 anf I find some issue in make of grub2
I modify the hello module by adding a new file a.c, with a function test() in it.
I call the function test from hello entry point - grub_cmd_hello()
When I do a make, I get the error that
test in hello is not defined
make: *** [moddep.lst] Error 1
I have modified the conf/common.mk accordingly as shown below.
# For hello.mod.
hello_mod_SOURCES = hello/hello.c hello/a.c
CLEANFILES += hello.mod mod-hello.o mod-hello.c pre-hello.o hello_mod-hello_hello.o hello_mod-hello_a.o und-hello.lst
ifneq ($(hello_mod_EXPORTS),no)
CLEANFILES += def-hello.lst
DEFSYMFILES += def-hello.lst
endif
MOSTLYCLEANFILES += hello_mod-hello_hello.d hello_mod-hello_a.d
UNDSYMFILES += und-hello.lst
hello.mod: pre-hello.o mod-hello.o
-rm -f $@
$(TARGET_CC) $(hello_mod_LDFLAGS) $(TARGET_LDFLAGS) -Wl,-r,-d -o $@ $^
$(STRIP) --strip-unneeded -K grub_mod_init -K grub_mod_fini -R .note -R .comment $@
pre-hello.o: $(hello_mod_DEPENDENCIES) hello_mod-hello_hello.o hello_mod-hello_a.o
-rm -f $@
$(TARGET_CC) $(hello_mod_LDFLAGS) $(TARGET_LDFLAGS) -Wl,-r,-d -o $@ hello_mod-hello_hello.o
mod-hello.o: mod-hello.c
$(TARGET_CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) $(hello_mod_CFLAGS) -c -o $@ $<
mod-hello.c: moddep.lst genmodsrc.sh
sh $(srcdir)/genmodsrc.sh 'hello' $< > $@ || (rm -f $@; exit 1)
ifneq ($(hello_mod_EXPORTS),no)
def-hello.lst: pre-hello.o
$(NM) -g --defined-only -P -p $< | sed 's/^\([^ ]*\).*/\1 hello/' > $@
endif
und-hello.lst: pre-hello.o
echo 'hello' > $@
$(NM) -u -P -p $< | cut -f1 -d' ' >> $@
hello_mod-hello_hello.o: hello/hello.c $(hello/hello.c_DEPENDENCIES)
$(TARGET_CC) -Ihello -I$(srcdir)/hello $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) $(hello_mod_CFLAGS) -MD -c -o $@ $<
-include hello_mod-hello_hello.d
hello_mod-hello_a.o: hello/a.c $(hello/a.c_DEPENDENCIES)
$(TARGET_CC) -Ihello -I$(srcdir)/hello $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) $(hello_mod_CFLAGS) -MD -c -o $@ $<
-include hello_mod-hello_a.d
CLEANFILES += cmd-hello_mod-hello_hello.lst fs-hello_mod-hello_hello.lst
COMMANDFILES += cmd-hello_mod-hello_hello.lst
FSFILES += fs-hello_mod-hello_hello.lst
cmd-hello_mod-hello_hello.lst: hello/hello.c $(hello/hello.c_DEPENDENCIES) gencmdlist.sh
set -e; $(TARGET_CC) -Ihello -I$(srcdir)/hello $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) $(hello_mod_CFLAGS) -E $< | sh $(srcdir)/gencmdlist.sh hello > $@ || (rm -f $@; exit 1)
cmd-hello_mod-hello_a.lst: hello/a.c $(hello/a.c_DEPENDENCIES) gencmdlist.sh
set -e; $(TARGET_CC) -Ihello -I$(srcdir)/hello $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) $(hello_mod_CFLAGS) -E $< | sh $(srcdir)/gencmdlist.sh hello > $@ || (rm -f $@; exit 1)
fs-hello_mod-hello_hello.lst: hello/hello.c $(hello/hello.c_DEPENDENCIES) genfslist.sh
set -e; $(TARGET_CC) -Ihello -I$(srcdir)/hello $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) $(hello_mod_CFLAGS) -E $< | sh $(srcdir)/genfslist.sh hello > $@ || (rm -f $@; exit 1)
fs-hello_mod-hello_a.lst: hello/a.c $(hello/a.c_DEPENDENCIES) genfslist.sh
set -e; $(TARGET_CC) -Ihello -I$(srcdir)/hello $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) $(hello_mod_CFLAGS) -E $< | sh $(srcdir)/genfslist.sh hello > $@ || (rm -f $@; exit 1)
Could anyone let me know whether I need to do anything more.
Viswesh
Explore your hobbies and interests. Go to http://in.promos.yahoo.com/groups/
[-- Attachment #2: Type: text/html, Size: 6046 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Linking
2008-07-25 5:17 Linking Viswesh S
@ 2008-07-25 5:35 ` Pavel Roskin
2008-07-25 15:18 ` Remove conf/*.mk from svn (was: Re: Linking) Colin D Bennett
1 sibling, 0 replies; 17+ messages in thread
From: Pavel Roskin @ 2008-07-25 5:35 UTC (permalink / raw)
To: grub-devel
Quoting Viswesh S <viswesh_vichu@yahoo.com>:
> I have modified the conf/common.mk accordingly as shown below.
It's a generated file. Please modify conf/common.rmk instead and run
autogen.sh.
--
Regards,
Pavel Roskin
^ permalink raw reply [flat|nested] 17+ messages in thread
* Remove conf/*.mk from svn (was: Re: Linking)
2008-07-25 5:17 Linking Viswesh S
2008-07-25 5:35 ` Linking Pavel Roskin
@ 2008-07-25 15:18 ` Colin D Bennett
2008-07-25 18:41 ` Remove conf/*.mk from svn Christian Franke
` (2 more replies)
1 sibling, 3 replies; 17+ messages in thread
From: Colin D Bennett @ 2008-07-25 15:18 UTC (permalink / raw)
To: grub-devel
On Thu, 24 Jul 2008 22:17:06 -0700 (PDT)
Viswesh S <viswesh_vichu@yahoo.com> wrote:
> I have modified the conf/common.mk accordingly as shown below.
GRUB developers,
I think we should remove conf/*.mk from the Subversion repository. If
people are going to be developing on GRUB and checking out svn
branches, then I think it's fine to require them to have Ruby. For
released tarballs that we expect non-developers to use, we just need to
generate the *.mk files and include them in the tarball.
What is the benefit of having conf/*.mk files in svn? They cause lots
of merge conflicts: sure, the conflicts are easy to resolve by simply
choosing to take one of the revisions, but then that merge really has
not meaning, since it won't be in sync with your .rmk file until it's
once again regenerated and checked in.
Removing the autogenerated .mk files would also eliminate problems new
developers like Viswesh and I have encountered -- we won't be tempted
to modify a non-versioned file like this.
Regards,
Colin
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Remove conf/*.mk from svn
2008-07-25 15:18 ` Remove conf/*.mk from svn (was: Re: Linking) Colin D Bennett
@ 2008-07-25 18:41 ` Christian Franke
2008-07-27 7:17 ` Pavel Roskin
2008-07-25 20:43 ` Remove conf/*.mk from svn (was: Re: Linking) Robert Millan
2008-08-05 10:40 ` Remove conf/*.mk from svn Marco Gerards
2 siblings, 1 reply; 17+ messages in thread
From: Christian Franke @ 2008-07-25 18:41 UTC (permalink / raw)
To: The development of GRUB 2
Colin D Bennett wrote:
> On Thu, 24 Jul 2008 22:17:06 -0700 (PDT)
> Viswesh S <...> wrote:
>
>
>> I have modified the conf/common.mk accordingly as shown below.
>>
>
> GRUB developers,
>
> I think we should remove conf/*.mk from the Subversion repository. If
> people are going to be developing on GRUB and checking out svn
> branches, then I think it's fine to require them to have Ruby. For
> released tarballs that we expect non-developers to use, we just need to
> generate the *.mk files and include them in the tarball.
>
> What is the benefit of having conf/*.mk files in svn? They cause lots
> of merge conflicts: sure, the conflicts are easy to resolve by simply
> choosing to take one of the revisions, but then that merge really has
> not meaning, since it won't be in sync with your .rmk file until it's
> once again regenerated and checked in.
>
> Removing the autogenerated .mk files would also eliminate problems new
> developers like Viswesh and I have encountered -- we won't be tempted
> to modify a non-versioned file like this.
>
>
I agree, the files generated by ./autogen.sh should be included in
tarball, but not in the repo.
Additional prerequisites (autoconf, ruby) for builds from svn are IMO OK.
In my local grub2 git repo, these files are excluded:
configure
config.h.in
stamp-h.in
conf/*.mk
BTW: autogen.sh should "touch stamp-h.in" to be consistent with the
Makefile rule for config.h.in.
Christian
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Remove conf/*.mk from svn (was: Re: Linking)
2008-07-25 15:18 ` Remove conf/*.mk from svn (was: Re: Linking) Colin D Bennett
2008-07-25 18:41 ` Remove conf/*.mk from svn Christian Franke
@ 2008-07-25 20:43 ` Robert Millan
2008-07-31 20:18 ` Yoshinori K. Okuji
2008-08-05 10:40 ` Remove conf/*.mk from svn Marco Gerards
2 siblings, 1 reply; 17+ messages in thread
From: Robert Millan @ 2008-07-25 20:43 UTC (permalink / raw)
To: The development of GRUB 2; +Cc: Yoshinori K. Okuji
On Fri, Jul 25, 2008 at 08:18:27AM -0700, Colin D Bennett wrote:
> On Thu, 24 Jul 2008 22:17:06 -0700 (PDT)
> Viswesh S <viswesh_vichu@yahoo.com> wrote:
>
> > I have modified the conf/common.mk accordingly as shown below.
>
> GRUB developers,
>
> I think we should remove conf/*.mk from the Subversion repository. If
> people are going to be developing on GRUB and checking out svn
> branches, then I think it's fine to require them to have Ruby. For
> released tarballs that we expect non-developers to use, we just need to
> generate the *.mk files and include them in the tarball.
>
> What is the benefit of having conf/*.mk files in svn? They cause lots
> of merge conflicts: sure, the conflicts are easy to resolve by simply
> choosing to take one of the revisions, but then that merge really has
> not meaning, since it won't be in sync with your .rmk file until it's
> once again regenerated and checked in.
>
> Removing the autogenerated .mk files would also eliminate problems new
> developers like Viswesh and I have encountered -- we won't be tempted
> to modify a non-versioned file like this.
I'd check with Okuji first. IIRC he didn't like that idea.
--
Robert Millan
<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Remove conf/*.mk from svn
2008-07-25 18:41 ` Remove conf/*.mk from svn Christian Franke
@ 2008-07-27 7:17 ` Pavel Roskin
2008-07-27 22:28 ` Christian Franke
0 siblings, 1 reply; 17+ messages in thread
From: Pavel Roskin @ 2008-07-27 7:17 UTC (permalink / raw)
To: The development of GRUB 2
On Fri, 2008-07-25 at 20:41 +0200, Christian Franke wrote:
> I agree, the files generated by ./autogen.sh should be included in
> tarball, but not in the repo.
> Additional prerequisites (autoconf, ruby) for builds from svn are IMO OK.
I agree.
At least we should put a message into *.mk files that would make it
clear that they are generated.
> BTW: autogen.sh should "touch stamp-h.in" to be consistent with the
> Makefile rule for config.h.in.
What difference would it make?
--
Regards,
Pavel Roskin
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Remove conf/*.mk from svn
2008-07-27 7:17 ` Pavel Roskin
@ 2008-07-27 22:28 ` Christian Franke
2008-07-28 22:43 ` Pavel Roskin
2008-08-05 10:38 ` Marco Gerards
0 siblings, 2 replies; 17+ messages in thread
From: Christian Franke @ 2008-07-27 22:28 UTC (permalink / raw)
To: The development of GRUB 2
Pavel Roskin wrote:
> On Fri, 2008-07-25 at 20:41 +0200, Christian Franke wrote:
>
>
>> I agree, the files generated by ./autogen.sh should be included in
>> tarball, but not in the repo.
>> Additional prerequisites (autoconf, ruby) for builds from svn are IMO OK.
>>
>
> I agree.
>
> At least we should put a message into *.mk files that would make it
> clear that they are generated.
>
>
Yes.
For a release tarball, It IMO also makes sense to include
util/parser.tab.c. It is platform-independent and rarely changed. This
would remove bison from the list of prerequisites.
>> BTW: autogen.sh should "touch stamp-h.in" to be consistent with the
>> Makefile rule for config.h.in.
>>
>
> What difference would it make?
>
>
$ patch < patch_changing_configure.ac_or_aclocal.m4
$ ./autogen.sh # runs autoheader etc.
$ ./configure
$ make # re-runs autoheader because stamp-h.in was not updated
Christian
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Remove conf/*.mk from svn
2008-07-27 22:28 ` Christian Franke
@ 2008-07-28 22:43 ` Pavel Roskin
2008-08-05 10:38 ` Marco Gerards
1 sibling, 0 replies; 17+ messages in thread
From: Pavel Roskin @ 2008-07-28 22:43 UTC (permalink / raw)
To: The development of GRUB 2
On Mon, 2008-07-28 at 00:28 +0200, Christian Franke wrote:
> Pavel Roskin wrote:
> > At least we should put a message into *.mk files that would make it
> > clear that they are generated.
> >
> >
>
> Yes.
Done.
> For a release tarball, It IMO also makes sense to include
> util/parser.tab.c. It is platform-independent and rarely changed. This
> would remove bison from the list of prerequisites.
It seems to me that gendistlist.sh should be rewritten from scratch.
It's completely outdated. It should sort its output in C locale for
consistency. It should be smart enough not to pick *.sh files for which
*.sh.in exists. It should include documentation and all C files barred
known exceptions (symlist.c, grub_*_init.c, mod-*.c)
Once gendistlist.sh is good enough to allow "make distcheck" to pass,
then we can do little adjustments and decide what should or should not
be in the distribution.
> >> BTW: autogen.sh should "touch stamp-h.in" to be consistent with
> the
> >> Makefile rule for config.h.in.
> >>
> >
> > What difference would it make?
> >
> >
>
>
> $ patch < patch_changing_configure.ac_or_aclocal.m4
>
> $ ./autogen.sh # runs autoheader etc.
>
> $ ./configure
>
> $ make # re-runs autoheader because stamp-h.in was not updated
Thanks. Fixed.
--
Regards,
Pavel Roskin
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Remove conf/*.mk from svn (was: Re: Linking)
2008-07-25 20:43 ` Remove conf/*.mk from svn (was: Re: Linking) Robert Millan
@ 2008-07-31 20:18 ` Yoshinori K. Okuji
0 siblings, 0 replies; 17+ messages in thread
From: Yoshinori K. Okuji @ 2008-07-31 20:18 UTC (permalink / raw)
To: The development of GRUB 2
On Friday 25 July 2008 22:43:10 Robert Millan wrote:
> On Fri, Jul 25, 2008 at 08:18:27AM -0700, Colin D Bennett wrote:
> > On Thu, 24 Jul 2008 22:17:06 -0700 (PDT)
> >
> > Viswesh S <viswesh_vichu@yahoo.com> wrote:
> > > I have modified the conf/common.mk accordingly as shown below.
> >
> > GRUB developers,
> >
> > I think we should remove conf/*.mk from the Subversion repository. If
> > people are going to be developing on GRUB and checking out svn
> > branches, then I think it's fine to require them to have Ruby. For
> > released tarballs that we expect non-developers to use, we just need to
> > generate the *.mk files and include them in the tarball.
> >
> > What is the benefit of having conf/*.mk files in svn? They cause lots
> > of merge conflicts: sure, the conflicts are easy to resolve by simply
> > choosing to take one of the revisions, but then that merge really has
> > not meaning, since it won't be in sync with your .rmk file until it's
> > once again regenerated and checked in.
> >
> > Removing the autogenerated .mk files would also eliminate problems new
> > developers like Viswesh and I have encountered -- we won't be tempted
> > to modify a non-versioned file like this.
>
> I'd check with Okuji first. IIRC he didn't like that idea.
I don't like. You can check the archive for my comments on this.
Regards,
Okuji
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Remove conf/*.mk from svn
2008-07-27 22:28 ` Christian Franke
2008-07-28 22:43 ` Pavel Roskin
@ 2008-08-05 10:38 ` Marco Gerards
1 sibling, 0 replies; 17+ messages in thread
From: Marco Gerards @ 2008-08-05 10:38 UTC (permalink / raw)
To: The development of GRUB 2
Hi,
Christian Franke <Christian.Franke@t-online.de> writes:
> For a release tarball, It IMO also makes sense to include
> util/parser.tab.c. It is platform-independent and rarely changed. This
> would remove bison from the list of prerequisites.
Fine for me.
--
Marco
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Remove conf/*.mk from svn
2008-07-25 15:18 ` Remove conf/*.mk from svn (was: Re: Linking) Colin D Bennett
2008-07-25 18:41 ` Remove conf/*.mk from svn Christian Franke
2008-07-25 20:43 ` Remove conf/*.mk from svn (was: Re: Linking) Robert Millan
@ 2008-08-05 10:40 ` Marco Gerards
2008-08-05 15:38 ` Vesa Jääskeläinen
2 siblings, 1 reply; 17+ messages in thread
From: Marco Gerards @ 2008-08-05 10:40 UTC (permalink / raw)
To: The development of GRUB 2
Hi,
Colin D Bennett <colin@gibibit.com> writes:
[...]
> I think we should remove conf/*.mk from the Subversion repository. If
> people are going to be developing on GRUB and checking out svn
> branches, then I think it's fine to require them to have Ruby. For
> released tarballs that we expect non-developers to use, we just need to
> generate the *.mk files and include them in the tarball.
I do not have problems with this. Besides this, it will stop people
from sending in patches with .mk changes in it :-)
--
Marco
^ permalink raw reply [flat|nested] 17+ messages in thread
* Seeking for the start
2008-08-05 15:48 ` Marco Gerards
@ 2008-08-05 12:02 ` administrador02032
2008-08-05 15:55 ` Remove conf/*.mk from svn Felix Zielcke
2008-08-05 18:41 ` Javier Martín
2 siblings, 0 replies; 17+ messages in thread
From: administrador02032 @ 2008-08-05 12:02 UTC (permalink / raw)
To: The development of GRUB 2
Hi:
I am new. You know. I have around two months studying grub. But I feel
myself lost. I understand the structure and the language. But I do not
have a start ( except boot's module ). What I want to know in general
terms is :
General characteristics of the kernel. (It was maded in order to do what?)
General characteristics out of every module.
I want knowing if exists some engineering design associated with grub and
his development.
I hope not to seem so lost as actually I seat myself.
Thanks
Alex
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Remove conf/*.mk from svn
2008-08-05 10:40 ` Remove conf/*.mk from svn Marco Gerards
@ 2008-08-05 15:38 ` Vesa Jääskeläinen
2008-08-05 15:48 ` Marco Gerards
0 siblings, 1 reply; 17+ messages in thread
From: Vesa Jääskeläinen @ 2008-08-05 15:38 UTC (permalink / raw)
To: The development of GRUB 2
Marco Gerards wrote:
> Colin D Bennett <colin@gibibit.com> writes:
>> I think we should remove conf/*.mk from the Subversion repository. If
>> people are going to be developing on GRUB and checking out svn
>> branches, then I think it's fine to require them to have Ruby. For
>> released tarballs that we expect non-developers to use, we just need to
>> generate the *.mk files and include them in the tarball.
>
> I do not have problems with this. Besides this, it will stop people
> from sending in patches with .mk changes in it :-)
I think Okuji's objection is based on fact that it makes it harder for
people to compile from sources. Now what if we would generate those
files when making a release? Of course this should be enabled to
script/makefile to make it automatically so it is not forgotten ;)
Thanks,
Vesa Jääskeläinen
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Remove conf/*.mk from svn
2008-08-05 15:38 ` Vesa Jääskeläinen
@ 2008-08-05 15:48 ` Marco Gerards
2008-08-05 12:02 ` Seeking for the start administrador02032
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: Marco Gerards @ 2008-08-05 15:48 UTC (permalink / raw)
To: The development of GRUB 2
Vesa Jääskeläinen <chaac@nic.fi> writes:
> Marco Gerards wrote:
>> Colin D Bennett <colin@gibibit.com> writes:
>>> I think we should remove conf/*.mk from the Subversion repository. If
>>> people are going to be developing on GRUB and checking out svn
>>> branches, then I think it's fine to require them to have Ruby. For
>>> released tarballs that we expect non-developers to use, we just need to
>>> generate the *.mk files and include them in the tarball.
>>
>> I do not have problems with this. Besides this, it will stop people
>> from sending in patches with .mk changes in it :-)
>
> I think Okuji's objection is based on fact that it makes it harder for
> people to compile from sources. Now what if we would generate those
> files when making a release? Of course this should be enabled to
> script/makefile to make it automatically so it is not forgotten ;)
Right. Just to be clear, personally I didn't have these objections
but Okuji has.
Actually, since ruby is required to generate these files, I guess we
can better keep the .mk files.
--
Marco
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Remove conf/*.mk from svn
2008-08-05 15:48 ` Marco Gerards
2008-08-05 12:02 ` Seeking for the start administrador02032
@ 2008-08-05 15:55 ` Felix Zielcke
2008-08-05 18:41 ` Javier Martín
2 siblings, 0 replies; 17+ messages in thread
From: Felix Zielcke @ 2008-08-05 15:55 UTC (permalink / raw)
To: The development of GRUB 2
Am Dienstag, den 05.08.2008, 17:48 +0200 schrieb Marco Gerards:
>
> Actually, since ruby is required to generate these files, I guess we
> can better keep the .mk files.
>
Just a little note from me:
The Debian package build depends already on ruby so this won't be a
problem for all Debian guys and especially not for Robert or me.
On Debian/Ubuntu you can just use 'apt-get build-dep grub2' and it
installs every package for you which you need to build grub2 so ruby
will be always needed/installed for the Debian package.
But well Debian isn't the only distribution and I don't know how others
deal with grub2 :)
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Remove conf/*.mk from svn
2008-08-05 15:48 ` Marco Gerards
2008-08-05 12:02 ` Seeking for the start administrador02032
2008-08-05 15:55 ` Remove conf/*.mk from svn Felix Zielcke
@ 2008-08-05 18:41 ` Javier Martín
2008-08-05 18:51 ` Colin D Bennett
2 siblings, 1 reply; 17+ messages in thread
From: Javier Martín @ 2008-08-05 18:41 UTC (permalink / raw)
To: The development of GRUB 2
[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]
El mar, 05-08-2008 a las 17:48 +0200, Marco Gerards escribió:
> Vesa Jääskeläinen <chaac@nic.fi> writes:
>
> > Marco Gerards wrote:
> >> Colin D Bennett <colin@gibibit.com> writes:
> >>> I think we should remove conf/*.mk from the Subversion repository. If
> >>> people are going to be developing on GRUB and checking out svn
> >>> branches, then I think it's fine to require them to have Ruby. For
> >>> released tarballs that we expect non-developers to use, we just need to
> >>> generate the *.mk files and include them in the tarball.
> >>
> >> I do not have problems with this. Besides this, it will stop people
> >> from sending in patches with .mk changes in it :-)
> >
> > I think Okuji's objection is based on fact that it makes it harder for
> > people to compile from sources. Now what if we would generate those
> > files when making a release? Of course this should be enabled to
> > script/makefile to make it automatically so it is not forgotten ;)
>
> Right. Just to be clear, personally I didn't have these objections
> but Okuji has.
>
> Actually, since ruby is required to generate these files, I guess we
> can better keep the .mk files.
Why not rewrite genmk.rb in a more common language (i.e. with an
interpreter more commonly found in stock GNU installs) like Python or
Perl?
Habbit
[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Remove conf/*.mk from svn
2008-08-05 18:41 ` Javier Martín
@ 2008-08-05 18:51 ` Colin D Bennett
0 siblings, 0 replies; 17+ messages in thread
From: Colin D Bennett @ 2008-08-05 18:51 UTC (permalink / raw)
To: grub-devel
On Tue, 05 Aug 2008 20:41:53 +0200
Javier Martín <lordhabbit@gmail.com> wrote:
> El mar, 05-08-2008 a las 17:48 +0200, Marco Gerards escribió:
> > Vesa Jääskeläinen <chaac@nic.fi> writes:
> >
> > > Marco Gerards wrote:
> > >> Colin D Bennett <colin@gibibit.com> writes:
> > >>> I think we should remove conf/*.mk from the Subversion
> > >>> repository. If people are going to be developing on GRUB and
> > >>> checking out svn branches, then I think it's fine to require
> > >>> them to have Ruby. For released tarballs that we expect
> > >>> non-developers to use, we just need to generate the *.mk files
> > >>> and include them in the tarball.
> > >>
> > >> I do not have problems with this. Besides this, it will stop
> > >> people from sending in patches with .mk changes in it :-)
> > >
> > > I think Okuji's objection is based on fact that it makes it
> > > harder for people to compile from sources. Now what if we would
> > > generate those files when making a release? Of course this should
> > > be enabled to script/makefile to make it automatically so it is
> > > not forgotten ;)
> >
> > Right. Just to be clear, personally I didn't have these objections
> > but Okuji has.
> >
> > Actually, since ruby is required to generate these files, I guess we
> > can better keep the .mk files.
> Why not rewrite genmk.rb in a more common language (i.e. with an
> interpreter more commonly found in stock GNU installs) like Python or
> Perl?
Fine with me. It shouldn't be too hard for someone who understands it.
Based on the discussions following my initial suggestion, it sounds
like it is considered too much work for people compiling from a svn
checkout to install Ruby?
Did I emphasize enough that released tarballs or any sort of archived
snapshot should be generated *with* the .mk files? I am concerned only
with the files under version control -- the point being that files
generated from often-modified files (such as the ``conf/*.rmk`` which
are often modified) have no business being under version control. I
think that this is even more important than lesser modified files such
as the configure script, etc., since fewer developers have to touch
that.
Regards,
Colin
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2008-08-05 20:30 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-07-25 5:17 Linking Viswesh S
2008-07-25 5:35 ` Linking Pavel Roskin
2008-07-25 15:18 ` Remove conf/*.mk from svn (was: Re: Linking) Colin D Bennett
2008-07-25 18:41 ` Remove conf/*.mk from svn Christian Franke
2008-07-27 7:17 ` Pavel Roskin
2008-07-27 22:28 ` Christian Franke
2008-07-28 22:43 ` Pavel Roskin
2008-08-05 10:38 ` Marco Gerards
2008-07-25 20:43 ` Remove conf/*.mk from svn (was: Re: Linking) Robert Millan
2008-07-31 20:18 ` Yoshinori K. Okuji
2008-08-05 10:40 ` Remove conf/*.mk from svn Marco Gerards
2008-08-05 15:38 ` Vesa Jääskeläinen
2008-08-05 15:48 ` Marco Gerards
2008-08-05 12:02 ` Seeking for the start administrador02032
2008-08-05 15:55 ` Remove conf/*.mk from svn Felix Zielcke
2008-08-05 18:41 ` Javier Martín
2008-08-05 18:51 ` Colin D Bennett
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.