linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Randy Dunlap <rdunlap@infradead.org>
To: Jayant Chowdhary <jchowdhary@google.com>,
	LKML <linux-kernel@vger.kernel.org>
Cc: linux-kbuild <linux-kbuild@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	kernel-team@android.com
Subject: Re: uapi headers userspace build results
Date: Tue, 12 Jun 2018 17:07:16 -0700	[thread overview]
Message-ID: <b5a73c3f-b70d-110f-896d-82fd81982cf8@infradead.org> (raw)
In-Reply-To: <1ef3a7b9-5172-9f7a-01fa-4866e765fbbe@google.com>

On 06/12/2018 01:39 PM, Jayant Chowdhary wrote:
> Hi Randy,
> 
> On 06/11/2018 10:49 PM, Randy Dunlap wrote:
>> Hi,
>>
>> Here is what I have so far.  It begins with a makefile and some
>> template files that are added to.  There's a good bit of Perl also.
>>
>> I put all of these files in tools/uapi/ and run them from there.
>>
>> There is one .c file generated for each .h file in builddir/usr/include
>> (O=builddir).
>>
> 
> Thanks for this! I wrote a small Makefile (uapi-compile.mk) which I'd put in
> tools/build (I can change this to tools/uapi, if that is more apt).

Your makefile foo is much better than mine is.
Yes, I think that it deserves to be in its own sub-directory.

> uapi-compile.mk straight-away compiles the uapi headers, without pulling them
> into any generated c source files. It may also be invoked with an environment

Hm, I didn't even know that is possible.

> variable 'UAPI_DIR' specifying the directory, for which the user would like to
> compile headers. This way we can test a directory at a time as well. In your

Yes, good, I was planning to make a way to restrict the build to certain sub-dirs.

> opinion, would this be simpler to have rather than having to auto-generate c
> source files including each uapi header and also autog-enerating the make
> targets? I feel like this approach would make maintaining these makefiles/
> scripts easier as well.

Sure, this is much better than my scripts.

>> Out of 889 header files, I see 45 errors.  That is better than I expected.
>>
>> The makefiles and scripts are attached (tar), as well as the output (I used
>> 'make -ik' so that make would keep going after errors and attempt to build
>> all target files).
>>
>> have fun!
>>
> 
> I did a 'make ARCH=arm64 headers_install' from the kernel source's root, and
> then a 'make -kf uapi-compile.mk all > build.log 2>&1' to compile all the
> headers. Out of 864 headers, I see 20 compilation failures.
> 
> I'm attaching uapi-compile.mk and the build.log file along.

I have some usage comments.

Since I ran 'make ARCH=x86_64 O=xx64 headers_install', I had to modify
uapi-compile.mk to use that SRC_DIR:

SRC_DIR :=../../xx64

Also, I first tried to make BDIR as a sub-directory of tools/uapi/ and
uapi-compile.mk did not work (when using BDIR=BDIR).
Then I did 'mkdir ../../xx64/BDIR' and specified BDIR=../../xx64/BDIR and
that worked.  But:  that sub-dir is not used:

gcc -I../../xx64/usr/include/ --include=../../xx64/usr/include/linux/posix_types.h --include=../../xx64/usr/include/asm-generic/ipcbuf.h --include=stdarg.h --include=stdint.h --include=stddef.h -c ../../xx64/usr/include//linux/caif/caif_socket.h -o ../../xx64/BDIR/../../xx64/usr/include//linux/caif/caif_socket.o
[see the next comment]

Oh, this makefile builds the .o files in the same sub-dirs as their
respective .h files.  I don't especially like that, but as long as
make clean works, it will do.  [and make clean does work]

Thanks.
-- 
~Randy

  reply	other threads:[~2018-06-13  0:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-12  5:49 uapi headers userspace build results Randy Dunlap
2018-06-12 20:39 ` Jayant Chowdhary
2018-06-13  0:07   ` Randy Dunlap [this message]
2018-06-19  1:47     ` Jayant Chowdhary
2018-06-19 18:17       ` Randy Dunlap
2019-05-27 22:12         ` Randy Dunlap
2019-05-28 17:06           ` Jayant Chowdhary

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=b5a73c3f-b70d-110f-896d-82fd81982cf8@infradead.org \
    --to=rdunlap@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=jchowdhary@google.com \
    --cc=kernel-team@android.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).