Re: [PATCH 0 of 1 ] RFC - Add CUSTOM version for gcc, binutils, libc, gdb

[Bryan Hundven <bryanhundven at gmail dot com>]

On Wed, Oct 3, 2012 at 9:46 PM, David Holsgrove
<david.holsgrove@xilinx.com> wrote:
> Hi Yann, All,
>
> Im sending the following feature addition as a request for interest on inclusion in CT-NG.
>
> Similar to the existing KERNEL_LINUX_CUSTOM option, I added a 'custom' version option for gcc, binutils, eglibc, glibc, newlib and gdb. These can be grabbed from a common source directory, or specified individually as a directory path or path to a tarball.
>
> This is useful for building against source during development on that component, or if the user wants to source control the component themselves using their own favourite system.
>
> The resultant CT_SRC_DIR could be setup like the following example then, depending on versions selected / paths provided;
>
> binutils-2.20.1a
> eglibc-custom -> ~/src_dev/rebase/eglibc
> gcc-custom -> ~/src_dev/gcc
> gdb-custom -> ~/src_dev/gdb
> gmp-5.0.2
> linux-custom -> ~/src_dev/v2/linux
> mpc-0.9
> mpfr-3.1.0
>
> I also considered making this depend on a DEVELOPER config option instead of just EXPERIMENTAL, would that be preferable?
>
> thanks,
> David
>
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
>

David, All,

Yann and I have talked about unifying the source acquisition helper
functions (CT_Get*) with a wrapper function to make getting custom
sources simpler.

Personally, I would like to see a way to add custom git, svn, cvs, hg,
(put your vcs here... maybe p4 :shrug:), individual files (think
sstrip.c), and tarballs in a clean maintainable way.

I have some changes laying around that need some finessing and
testing, and then I plan on pushing them here.

If we went down the route that you've proposed, I know that Yann would
want each component in a separate change. So gcc in one patch,
(e)glibc in another, etc. Just a tip.

-Bryan

--
For unsubscribe information see http://sourceware.org/lists.html#faq