Re: [PATCH 2 of 3] config/cc: CC_STATIC_LIBSTDCXX 'depends on' CONFIGURE_has_static_libstdcpp

[Bryan Hundven <bryanhundven at gmail dot com>]

On Tue, May 31, 2011 at 5:04 PM, Yann E. MORIN
<yann.morin.1998@anciens.enib.fr> wrote:
> Bryan, All,
>
> On Tuesday 31 May 2011 16:36:32 Bryan Hundven wrote:
>> On Tue, May 31, 2011 at 5:13 AM, Yann E. MORIN
>> <yann.morin.1998@anciens.enib.fr> wrote:
> [--SNIP--]
>> > +# In case we need to add more conditions to enable static
>> > +# toolchain, we'll be adding them here
>> > +config STATIC_TOOLCHAIN_POSSIBLE
>> > + Â Âbool
>> > + Â Âdefault y
>> > + Â Âdepends on CONFIGURE_has_static_libstdcxx
>> > + Â Â# Add new deps here! :-)
>> > +
>>
>> Why? I don't understand why you want a config option with its own set
>> of dependencies... this will cause more problems in the future then
>> will solve. Another patch I don't get.
>>
>> Why not just put the dependency in STATIC_TOOLCHAIN where it belongs?
>
> For this particular case, I agree with you: adding the dependency directly
> to the affected symbol would be more appropriate.
>
> On the other hand, this is begining to be quite complex, and I envision a
> situation where the list of dependencies could grow very, very quickly. To
> keep that kconfig part readable, it seems more fit to move the CONFIGURE_*
> dependencies to an intermediate symbol.
>
> Apart from the required static libstdc++, we also need to check for other
> libs static format being available. At least we need libc.a, probably libm.a
> and a few others.
>
> Another reason is that we may have to disable shared building, and be able
> to force static build. Having separate intermediate symbols for the deps
> will highly simplify that kconfig part.

When you start adding more languages (gnat, objc(++), java... go(?)),
each has a set of dependencies.
A majority of the problems we see on this mailing list are because the
user (person running ct-ng, developer or not...) doesn't have the
correct dependencies installed on the build host. And if you want to
spend most of your time tracking down a missing dependencies, be my
guest.
I think that we should stop and re-factor things so that we _can_
check for build host dependencies in a way that doesn't make ct-ng
complex.
It might squeeze out some other issues indirectly, which would be
nice. It also might provide a good dependency framework that
llvm/clang or whatever else you want to shoe horn into ct-ng.

Just my 2cents.

But as I said in irc, this is your project and you do what you see
fit. I am merely providing advise via patch (or mq in this case).

>> > Âconfig STATIC_TOOLCHAIN
>> > Â Â bool
>> > Â Â prompt "Build Static Toolchain (EXPERIMENTAL)"
>> > Â Â depends on EXPERIMENTAL
>> > + Â Âdepends on STATIC_TOOLCHAIN_POSSIBLE
>> > Â Â default n
>> > Â Â help
>> > Â Â Â Build static host binaries.
>
> Regards,
> Yann E. MORIN.
>
> --
> .-----------------.--------------------.------------------.--------------------.
> | ÂYann E. MORIN Â| Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software ÂDesigner | \ / CAMPAIGN Â Â | Â___ Â Â Â Â Â Â Â |
> | +33 223 225 172 `------------.-------: ÂX ÂAGAINST Â Â Â| Â\e/ ÂThere is no Â|
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL  Â|  v  conspiracy. Â|
> '------------------------------^-------^------------------^--------------------'
>

-Bryan

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