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
prev parent 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