Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Ulf Samuelsson <ulf@atmel.com>
To: buildroot@busybox.net
Subject: [Buildroot] Several issues with building multiple"projects"	for same architecture
Date: Tue, 30 Oct 2007 08:41:54 +0100	[thread overview]
Message-ID: <003101c81ac8$75b4be60$01c4af0a@Glamdring> (raw)
In-Reply-To: 20071030001045.GA5198@cloud.net.au

On Mon, Oct 29, 2007 at 11:50:07PM +0100, Ulf Samuelsson wrote:
> m?n 2007-10-29 klockan 10:55 -0500 skrev Jonathan Nalley:
> > I am using the buildroot to build for several different boards, some
> > of them have the same CPU architecture (PPC405GP/EP).  I have noticed
> > some issues with the "project" concept in the buildroot.  Since the
> > builds are for the same architecture the toolchain is created under
> > "build_powerpc".  Everything works fine for the first board, but for
> > subsequent builds for different "project" names things are missing
> > under "project_build_powerpc/PROJECT_NAME/root".  Specifically:
> >
> > /root/lib/libgcc_s.so
> > /root/usr/lib/libstdc++.so
> > /root/usr/sbin/ethtool
> >
> > This is because the make files that install those files check for:
> >
> > $(GCC_BUILD_DIR2)/.libs_installed

There's another problem with this approach. If you are modifying the
target_skeleton contents you might want to nuke the generated root
directory and have it rebuilt, but then libgcc_s.so (etc) won't be
re-copied.

> Here is a first attempt to fix this,
> I have not tested it yet myself though.
>
> The idea is to create a $(DEP_DIR) directory in $(PROJECT_BUILD_DIR)
> and then to generate a $(<package>).installed in this directory.

This doesn't solve the problem I note either, although I guess you could
also delete *.installed. Why not just depend on the actual target rather
than these stamp files?

==> The proper way of installing a package is often "make install".
        Question is which files should be copied and in which order.

        If you depend on an arbitrary file, then you risk that
        the build fails if not all files are copied, but the file,
         on which we depend *is* copied

        If you detect the order and make it depend on the latest
        then you have a problem if the package is updated
        and the order is changed or if new files are introduced
        by make install.

        You also have a problem if the package has options.

        One possible option is to create the .installed
        inside the root file ssytem, but then you add unneccessary
        files to your target system.

        If you want to rebuild the project from scratch, then you
        might as well delete the complete $(PROJECT_BUILD_DIR)
        instead of the root file system.

        Note that my fix does not handle the "package/Makefile.in.autotools"
        Someone obviously needs to fix that as well.

Best Regards
Ulf Samuelsson

      reply	other threads:[~2007-10-30  7:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-29 15:55 [Buildroot] Several issues with building multiple "projects" for same architecture Jonathan Nalley
2007-10-29 17:33 ` Bernhard Fischer
2007-10-29 18:22 ` [Buildroot] Several issues with building multiple "projects" forsame architecture Ulf Samuelsson
2007-10-29 22:50 ` [Buildroot] Several issues with building multiple "projects" for same architecture Ulf Samuelsson
2007-10-30  0:10   ` Hamish Moffatt
2007-10-30  7:41     ` Ulf Samuelsson [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='003101c81ac8$75b4be60$01c4af0a@Glamdring' \
    --to=ulf@atmel.com \
    --cc=buildroot@busybox.net \
    /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