[kbuild-devel] Re: kbuild 1.3 comments and bugs
Apologies for the delay. You raised some good points so I put the mail
one side to think about then forgot it was in my drafts folder.
On Sat, 29 Sep 2001 17:05:57 +0200,
"Giacomo A. Catenazzi" <[EMAIL PROTECTED]> wrote:
>BUG:
>
>$ make mrproper
>$ make mrproper
>Error: you must create a .config first
>
>mrproper should not depend on .config (contents and
>existance).
kbuild 2.4 relies on everybody coding the mrproper targets at the top
level which is manual and error prone. kbuild 2.5 automatically
generates the mrproper targets from each Makefile.in, the disadvantage
is that it needs a config to do that. However that only applies if
source and object are in the same directory, if you use a separate
object directory then make mrproper simply erases everything in the
object directory. I am willing to accept the need to have a config to
do make mrproper to get an automatic cleanup.
>COMMENT:
>
>Your documentation is extensive, but I didn't found
>the meaning of targets.
Which targets?
>I think that now (with kbuild) we can nearly always
>replace mrproper with clean. (and mrproper will
>do clean + rm .config).
mrproper removes the support files like scripts/pp_makefile[1-4] as
well as all the user generated binaries and headers. Clean only gets
rid of the kernel related files.
>BUG ?
>
>making arch/i386/boot/bbotsect.o:
>old:
> bbootsect.s: Assembler message:
> bbootsect.s:257: Warning
>new:
> /tmp/ccM: Assempler message
> /tmp/ccM5???:257" Warning ...
>
>What is the more user-friendly message?
>The cause: you forget '-pipe'.
-pipe does not really help. Instead of /tmp/ccM, -pipe results in
messages for {standard input}. kbuild 2.4 displays the .s name because
bbootsect.o is built in two stages, bbootsect.S -> bbootsect.s ->
bbootsect.o. I will look at doing a two stage conversion in kbuild 2.5
for .S files. The second stage would use $(AS) instead of $(CC).
>COMMENT
>
>You should change the number of the phases.
>I really don't like phase 5 before phase 4.
>(Let a missing phase number of first compile,
>but let the pahse always be in order)
Phase 5 is feedback from the previous run, its numbering reflects that
it is a continuation of the previous build. However I expect to remove
phase 5 anyway, when I replace the individual .d and .cd files with a
global database. That will significantly speed things up.
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: kbuild 1.3 comments and bugs
Keith Owens wrote:
>
> On Sat, 29 Sep 2001 17:05:57 +0200,
> "Giacomo A. Catenazzi" <[EMAIL PROTECTED]> wrote:
>
>>BUG:
>>
>>$ make mrproper
>>$ make mrproper
>>Error: you must create a .config first
>>
>>mrproper should not depend on .config (contents and
>>existance).
>>
>
> kbuild 2.4 relies on everybody coding the mrproper targets at the top
> level which is manual and error prone. kbuild 2.5 automatically
> generates the mrproper targets from each Makefile.in, the disadvantage
> is that it needs a config to do that. However that only applies if
> source and object are in the same directory, if you use a separate
> object directory then make mrproper simply erases everything in the
> object directory. I am willing to accept the need to have a config to
> do make mrproper to get an automatic cleanup.
Maybe a better solution: mrproper don't depend on .config.
If .config exists, do the actual make mrproper, else
do nothing. (or maybe cancel the ev. cml[12] generated file.
(This means you rename mrproper to mrproper-r and implement
an other mrproper. This would be an exception: make will call
another make).
>
>
>>COMMENT:
>>
>>Your documentation is extensive, but I didn't found
>>the meaning of targets.
>>
>
> Which targets?
>
target: mrproper, clean, installable, ...
BTW I didn't like "installable". Use something more ... liek a linusism,
like make world/linux/domination/free/penguin
>
>
>>BUG ?
>>
>>making arch/i386/boot/bbotsect.o:
>>old:
>>bbootsect.s: Assembler message:
>>bbootsect.s:257: Warning
>>new:
>>/tmp/ccM: Assempler message
>>/tmp/ccM5???:257" Warning ...
>>
>>What is the more user-friendly message?
>>The cause: you forget '-pipe'.
>>
>
> -pipe does not really help. Instead of /tmp/ccM, -pipe results in
> messages for {standard input}. kbuild 2.4 displays the .s name because
> bbootsect.o is built in two stages, bbootsect.S -> bbootsect.s ->
> bbootsect.o. I will look at doing a two stage conversion in kbuild 2.5
> for .S files. The second stage would use $(AS) instead of $(CC).
>
Sorry for my stupid comment. The main issue was that "kbild-2.4" use
-pipe in AS flags, kbuild-2.5 no.
>
>>COMMENT
>>
>>You should change the number of the phases.
>>I really don't like phase 5 before phase 4.
>>(Let a missing phase number of first compile,
>>but let the pahse always be in order)
>>
>
> Phase 5 is feedback from the previous run, its numbering reflects that
> it is a continuation of the previous build. However I expect to remove
> phase 5 anyway, when I replace the individual .d and .cd files with a
> global database. That will significantly speed things up.
>
More speedup? Should I insert a sleep 1 before every file build to not
burn my laptop? :-)
To speed-up more, you can remove default the verbose things in your make scripts.
(with preprocessor instead of runtime)
If user use a makefile parameter VERBOSE, the makefile vould be build verbose.
giacomo
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: kbuild 1.3 comments and bugs
On Wed, 10 Oct 2001 16:39:16 +0200, Giacomo Catenazzi <[EMAIL PROTECTED]> wrote: >Keith Owens wrote: >Maybe a better solution: mrproper don't depend on .config. I convert user_command() to 'make' rules in place, so the result replaces user_command(). The expanded commands automatically add to the CLEAN list. Some user_commands() are conditional on CONFIG_xxx so I need a .config to get the correct expansion of the global Makefile. The MRPROPER list includes the CLEAN list. Without a .config I have no CLEAN list. >To speed-up more, you can remove default the verbose things in your make scripts. >(with preprocessor instead of runtime) >If user use a makefile parameter VERBOSE, the makefile vould be build verbose. The generated global Makefile has variables like KBUILD_QUIET and PP_MAKEFILE3_FLAGS. I deliberately left this for make to evaluate instead of doing them during the generation phase. That lets you debug kbuild quickly by specifying the failing target, NO_MAKEFILE_GEN (bypass pre-processor) plus the debug flags to see what is occurring. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: kbuild 1.3 comments and bugs
Keith Owens wrote:
> On Wed, 10 Oct 2001 16:39:16 +0200,
> Giacomo Catenazzi <[EMAIL PROTECTED]> wrote:
>
>>Keith Owens wrote:
>>Maybe a better solution: mrproper don't depend on .config.
>>
>
> I convert user_command() to 'make' rules in place, so the result
> replaces user_command(). The expanded commands automatically add to
> the CLEAN list. Some user_commands() are conditional on CONFIG_xxx so
> I need a .config to get the correct expansion of the global Makefile.
> The MRPROPER list includes the CLEAN list. Without a .config I have
no
> CLEAN list.
>
what I propose:
mrproper:
if [ -f .config ]; then ${MAKE} true_mrproper
else
rm -f ${explicit list of file that could exists \
before .config (cml2 and kbuild files)}
fi
[this is untested simplified version, and it shouldn't work with
shadow tree, but do shadows tree exists without .config?]
Reading again your sentences I have another question (yet I don't
have access on Linux boxes).
If I do:
make menuconfig installable
make menuconfig
# and I change the configurations
make installable
make mrproper
Would this clean the files generated only on first
'installable' ?
>
>>To speed-up more, you can remove default the verbose things in your
make scripts.
>>(with preprocessor instead of runtime)
>>If user use a makefile parameter VERBOSE, the makefile vould be build
verbose.
>>
>
> The generated global Makefile has variables like KBUILD_QUIET and
> PP_MAKEFILE3_FLAGS. I deliberately left this for make to evaluate
> instead of doing them during the generation phase. That lets you
debug
> kbuild quickly by specifying the failing target, NO_MAKEFILE_GEN
> (bypass pre-processor) plus the debug flags to see what is occurring.
Ok. It was only a proposal. I agree with KBUILD_QUIET, but I think
nobody (else kbuild's people) need PP_MAKEFILE3_FLAGS.
Hmm, anyway the speed up is minimal, thus forget this proposal.
giacomo
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
