On Thu, Sep 03, 2015 at 02:56:35PM +0900, Masao Uebayashi wrote:
> Because ${OBJS} affects not only build order but also link order.
and that's exactly why it *should* be sorted. Please don't introduce
sources of instability to the build process.
Joerg
Masao Uebayashi writes:
> They were intentionally overly strict. Please put them back. Or
> change them to not overly strict.
there's no good reason to change either makeoptions to to force all options
to be listed in the files files. like most of the items in config/TODO,
there is no
On Thu, Sep 03, 2015 at 02:56:35PM +0900, Masao Uebayashi wrote:
> Because ${OBJS} affects not only build order but also link order.
And this matters why, in the absence of e.g. profile-driven function
layout?
(although it might be interesting to see if running ${OBJS} through
lorder/tsort
I got some errors from common/lib/libc/arch/arm/features.mk. Will
revisit later.
They were intentionally overly strict. Please put them back. Or
change them to not overly strict.
You make me wonder if I should add this to Makefile.kern.nc:
${SYSTEM_OBJ}: Makefile
On Thu, Sep 3, 2015 at 11:32 PM, Joerg Sonnenberger
wrote:
> On Thu, Sep 03, 2015 at 02:56:35PM +0900, Masao Uebayashi wrote:
>> Because ${OBJS} affects not only build order but also link order.
>
> and that's exactly why it *should* be sorted. Please don't introduce
>
I will bring this back to track once things will settle.
My plan is to order objects following module dependency for kernel constructors.
Masao Uebayashi writes:
> On Fri, Sep 4, 2015 at 4:10 AM, matthew green wrote:
> > Masao Uebayashi writes:
> >> They were intentionally overly strict. Please put them back. Or
> >> change them to not overly strict.
> >
> > there's no good reason to change either makeoptions