From: Nicholas Mc Guire <der.herr@hofr.at>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: Michal Marek <mmarek@suse.cz>,
Christoph Hellwig <hch@infradead.org>,
Joe Perches <joe@perches.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] handling of _shipped files
Date: Wed, 1 Oct 2014 20:15:33 +0200 [thread overview]
Message-ID: <20141001181533.GB13544@opentech.at> (raw)
In-Reply-To: <542C3F3B.9010400@infradead.org>
On Wed, 01 Oct 2014, Randy Dunlap wrote:
> On 10/01/14 06:36, Nicholas Mc Guire wrote:
> >
> > handling of _shipped files
> >
> > This adds a section on handling of _shipped files in kbuild
> > Makefiles and the build process.
> >
> > Signed-off-by: Nicholas Mc Guire <der.herr@hofr.at>
> > ---
> > Documentation/kbuild/makefiles.txt | 57 +++++++++++++++++++++++++++++++++++-
> > 1 file changed, 56 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
> > index 764f599..d0bd91a 100644
> > --- a/Documentation/kbuild/makefiles.txt
> > +++ b/Documentation/kbuild/makefiles.txt
> > @@ -19,6 +19,7 @@ This document describes the Linux kernel Makefiles.
> > --- 3.10 Special Rules
> > --- 3.11 $(CC) support functions
> > --- 3.12 $(LD) support functions
> > + --- 3.13 _shipped - generated files
> >
> > === 4 Host Program support
> > --- 4.1 Simple Host Program
> > @@ -595,6 +596,60 @@ more details, with real examples.
> > LDFLAGS_vmlinux += $(call ld-option, -X)
> >
> >
> > +--- 3.13 _shipped - generated files
> > +
> > + Some sources in the kernel are generated by tools or special
> > + purpose scrips so that the build process dependencies can be kept
>
> scripts
>
> > + at a resonable level. Also in cases where the translation is not
>
> reasonable
>
> > + configuration dependent but might impact build time _shipped files
>
> build time,
>
> > + may be added along with the actual sources to speed up the build
> > + process.
> > +
> > + For standard tools like lex and yacc the make process will actually
> > + generate the _shipped files (see scripts/Makefile.lib) and retain
> > + them by marking them .PRECIOUS so they are not removed by the clean
> > + targets.
> > +
> > + For non standard tools the generation of the _shipped file it self
>
> non-standard itself
>
> > + may be manually achived by building and then renaming. A makefile
>
> achieved
>
> > + target for generate the actual target file should to be provided
>
> to generate
>
> > + though and can be conditioned on an environment variable.
>
> Most examples that I see just expect the Makefile to be modified to set
> (or define) the variable.
>
Yes - but is that the prefered way of doing it ? I guess it
would be more clear to have a variable that is taken from the
environment and not via .config to trigger a conditional rebuild
as the defkeymap example does it.
> > +
> > + Example:
> > + ifdef GENERATE_KEYMAP
> > +
> > + $(obj)/defkeymap.c: $(obj)/%.c: $(src)/%.map
> > + loadkeys --mktable $< > $@
> > +
> > + endif
> > +
> > + The _shipped file does not appear in the actual Makefile, this is
> > + handled by the rules found in scripts/Makefile.lib.
> > +
> > + <snip>
> > + cmd_shipped = cat $< > $@
> > +
> > + $(obj)/%: $(src)/%_shipped
> > + $(call cmd,shipped)
> > + <snip>
> > +
> > + which simply will copy the target_shipped to the target
> > +
> > + If a file of a make target is found in the build directory with the
> > + extension _shipped make will used it, rather than generating the
>
> _shipped, make will use it rather than generating the
>
> > + respective target file from source.
> > +
> > + The build will indicate the use of the _shipped file by the SHIPPED
> > + quiet command in the make output.
> > +
> > + Example:
> > + LD drivers/scsi/aic7xxx/built-in.o
> > + SHIPPED drivers/scsi/aic7xxx/aic79xx_seq.h
> > + SHIPPED drivers/scsi/aic7xxx/aic79xx_reg.h
> > + CC [M] drivers/scsi/aic7xxx/aic79xx_core.o
> > + CC [M] drivers/scsi/aic7xxx/aic79xx_pci.o
> > + SHIPPED drivers/scsi/aic7xxx/aic79xx_reg_print.c
> > + CC [M] drivers/scsi/aic7xxx/aic79xx_reg_print.o
> > === 4 Host Program support
> >
> > Kbuild supports building executables on the host for use during the
> > @@ -1423,10 +1478,10 @@ Original version made by Michael Elizabeth Chastain, <mailto:mec@shout.net>
> > Updates by Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
> > Updates by Sam Ravnborg <sam@ravnborg.org>
> > Language QA by Jan Engelhardt <jengelh@gmx.de>
> > +Kbuild support for shipped files Nicholas Mc Guire <der.herr@hofr.at>
> >
> > === 11 TODO
> >
> > -- Describe how kbuild supports shipped files with _shipped.
> > - Generating offset header files.
> > - Add more variables to section 7?
> >
> >
>
and thanks for the language fixes - thought I had spellchecked it but
obviously I did not
thx!
hofrat
prev parent reply other threads:[~2014-10-01 18:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-01 13:36 [PATCH 1/3] handling of _shipped files Nicholas Mc Guire
2014-10-01 17:51 ` Randy Dunlap
2014-10-01 18:15 ` Nicholas Mc Guire [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141001181533.GB13544@opentech.at \
--to=der.herr@hofr.at \
--cc=hch@infradead.org \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mmarek@suse.cz \
--cc=rdunlap@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox