[prev in list] [next in list] [prev in thread] [next in thread]
List: coreutils
Subject: Re: Building a subset of coreutils
From: Paul Moore <p.f.moore () gmail ! com>
Date: 2013-05-13 19:18:27
Message-ID: CACac1F_HRVEXxPzH3svtq8H9B6NQkMRa4SF=YngE4m_OFSmE4A () mail ! gmail ! com
[Download RAW message or body]
On 13 May 2013 20:04, Eric Blake <eblake@redhat.com> wrote:
> On 05/13/2013 12:41 PM, Paul Moore wrote:
> > I'm taking my first steps at building coreutils from scratch, and I'm
> > interested in how I would limit the build to a subset of the full list of
> > tools. From my investigations, it seems to me that I can modify
> > build-aux/gen-lists-of-programs.sh to limit the list of tools that get
> > built - but that does not seem to remove the unneeded parts of gnulib. It
> > looks like I can remove the parts of gnulib that I don't need by
> modifying
> > bootstrap.conf.
> >
> > However, short of manually analysing each of the tools that I include, I
> > don't see a way of determining which gnulib functions can be omitted -
> i.e.
> > a list of which tools use which gnulib facilities.
> >
> > As an example, if I *just* wanted to build numfmt, sort, and date, how
> > would I establish what to include?
>
> I would just let gnulib do its thing. It's built as a static library,
> so even though you spend more time than necessary building files that
> aren't used in the subset of executables you want, you aren't bloating
> your resulting binaries any. Furthermore, gnulib tries to build as
> little as possible; if you have an up-to-date GNU/Linux system, there's
> already quite a few source files of gnulib that aren't even built
> because you have no bugs to be worked around in the first place.
Sorry, I should have given a bit more of my background. There are two
reasons for doing this. The first is purely educational, I want to try to
understand how the autoconf/automake/gnulib infrastructure all works - up
until now, I've just been an "end user", using what was generated, but I
want to try to understand how it all actually works (and yes, I know
coreutils is ridiculously complicated for a beginner, but the toy examples
I have seen are *too* simple, and I don't have any examples of my own). The
manuals are fine, but I find that hacking on a "real" example is far more
informative.
The second reason is that I want to try to "strip out" the parts of
coreutils that are pure text processing (things like sort, numfmt, date,
... as I mentioned) with the intention of trying to get them to compile on
Windows. For that to work, I need to remove the parts of gnulib (like
mountlist and userspec) that simply won't compile on Windows. That's the
bit that makes "just letting gnulib do its thing" impossible - although I
guess I could use make -k to skip the build failures for those modules, so
that might be an option...
I hope this clarifies, and apologies for being vague in my original post.
Paul.
[Attachment #3 (text/html)]
<div dir="ltr">On 13 May 2013 20:04, Eric Blake <span dir="ltr"><<a \
href="mailto:eblake@redhat.com" target="_blank">eblake@redhat.com</a>></span> \
wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <div class="HOEnZb"><div class="h5">On 05/13/2013 12:41 PM, \
Paul Moore wrote:<br> > I'm taking my first steps at building coreutils from \
scratch, and I'm<br> > interested in how I would limit the build to a subset \
of the full list of<br> > tools. From my investigations, it seems to me that I can \
modify<br> > build-aux/gen-lists-of-programs.sh to limit the list of tools that \
get<br> > built - but that does not seem to remove the unneeded parts of gnulib. \
It<br> > looks like I can remove the parts of gnulib that I don't need by \
modifying<br> > bootstrap.conf.<br>
><br>
> However, short of manually analysing each of the tools that I include, I<br>
> don't see a way of determining which gnulib functions can be omitted - \
i.e.<br> > a list of which tools use which gnulib facilities.<br>
><br>
> As an example, if I *just* wanted to build numfmt, sort, and date, how<br>
> would I establish what to include?<br>
<br>
</div></div>I would just let gnulib do its thing. It's built as a static \
library,<br> so even though you spend more time than necessary building files \
that<br> aren't used in the subset of executables you want, you aren't \
bloating<br> your resulting binaries any. Furthermore, gnulib tries to build as<br>
little as possible; if you have an up-to-date GNU/Linux system, there's<br>
already quite a few source files of gnulib that aren't even built<br>
because you have no bugs to be worked around in the first \
place.</blockquote><div><br></div><div style>Sorry, I should have given a bit more of \
my background. There are two reasons for doing this. The first is purely educational, \
I want to try to understand how the autoconf/automake/gnulib infrastructure all works \
- up until now, I've just been an "end user", using what was generated, \
but I want to try to understand how it all actually works (and yes, I know coreutils \
is ridiculously complicated for a beginner, but the toy examples I have seen are \
*too* simple, and I don't have any examples of my own). The manuals are fine, but \
I find that hacking on a "real" example is far more informative.</div> <div \
style><br></div><div style>The second reason is that I want to try to "strip \
out" the parts of coreutils that are pure text processing (things like sort, \
numfmt, date, ... as I mentioned) with the intention of trying to get them to compile \
on Windows. For that to work, I need to remove the parts of gnulib (like mountlist \
and userspec) that simply won't compile on Windows. That's the bit that makes \
"just letting gnulib do its thing" impossible - although I guess I could \
use make -k to skip the build failures for those modules, so that might be an \
option...</div> <div style><br></div><div style>I hope this clarifies, and apologies \
for being vague in my original post.</div><div style><br></div><div \
style>Paul.</div></div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic