All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@domain.hid>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: xenomai@xenomai.org
Subject: [Xenomai-core] Re: --enable-linux-build
Date: Wed, 18 Jan 2006 19:30:51 +0100	[thread overview]
Message-ID: <43CE895B.9060506@domain.hid> (raw)
In-Reply-To: <17357.6643.403829.486469@domain.hid>

[-- Attachment #1: Type: text/plain, Size: 2179 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Hi Gilles,
>  > 
>  > I just tested your new build option. Maybe I'm using it the wrong way,
>  > but I stumbled over two quirks:
>  > 
>  >  o "make install-nodev" fails as it tries to install the kernel without
>  >    being root. Actually, I only wanted to install the user space part,
>  >    how can I do this separately? Or is this rather a use-case for the
>  >    standard build?
> 
> I did not think about this case. Any idea of what would be better ? Not
> installing kernel when running "make install-nodev" ? Creating 
> install-nokernel and install-nokernel-nodev targets ?

I would suggest "make install-user" instead of "make install-nodev",
combining both -nodev and -nokernel, i.e. excluding everything that
requires root permissions.

> 
>  > 
>  >  o On every "make", the prepare-kernel script is executed -
>  >    intentionally? Maybe it would be better to provide a dedicated make
>  >    target to trigger the update.
> 
> prepare-kernel should be executed whenever any file or directory is
> added in the ksrc and include dirs. On my own machine, prepare-kernel is
> much shorter than the kernel build. So, I did not see this as an issue,
> but I am ready to accept any better solution. Maybe it could depend on
> maintainer mode ? Since the user-space will work automatically when
> adding a file or directory only if maintainer mode is enabled.
> 

Yes, this looks good - as long as it is still run on the first make or
during configure.

The point is that I have a non-developer use-case for your build mode in
mind were you do not constantly add files to the xeno code base, but
reconfigure your kernel from time to time: We have mini distribution
here which can optionally be build from source. In that case, you could
soon decide to build
 ( ) Vanilla kernel
 (*) Xenomai-extended kernel and libraries
instead of
 ( ) Vanilla kernel
 (*) Xenomai-extended kernel
   [*] Xenomai libraries
(not to speak about what currently happens in the background...)

Could make life of the maintainer and users here a bit easier.

Thanks for caring,
Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

      reply	other threads:[~2006-01-18 18:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-17 16:09 [Xenomai-core] --enable-linux-build Jan Kiszka
2006-01-17 16:23 ` [Xenomai-core] --enable-linux-build Gilles Chanteperdrix
2006-01-18 18:30   ` Jan Kiszka [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=43CE895B.9060506@domain.hid \
    --to=jan.kiszka@domain.hid \
    --cc=gilles.chanteperdrix@xenomai.org \
    --cc=xenomai@xenomai.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 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.