On Mon, 30 Oct 2000 15:15:57 -0800 (PST),
Linus Torvalds <torvalds@transmeta.com> wrote:
>I'm saying that EVERYTHING should be order-critical.
We (almost) agree about that, we are arguing about implementation
details. The existing implementation relies on the order that objects
are declared. In almost all cases there are no documented reasons for
the existing order, people who know about the link order problems are
scared to change declaration orders. OTOH, relying on declaration
order is error prone, people who do not know about the side effects of
declaration order try to change it and sometimes it works, sometimes it
breaks.
kbuild 2.5 splits link order into three categories. Those that must
come first, in the order they are specified - LINK_FIRST. Those that
must come last, in the order they are specified - LINK_LAST.
Everything else, in no defined order. This solves the documentation
problem, use of LINK_FIRST and LINK_LAST is explicit and the reasons
for the order will be documented, or else! Declaration order is then
irrelevant, it can be any order that makes sense to the developers.
The end effect if the same, LINK_FIRST/LAST is a better implementation.
>It is NEVER acceptable to change the order of object files.
It is NEVER acceptable to change the order of object files, but only
for those files where the developer has explicitly said what the order
must be. In the case of USB, the developers say usb.o must be first,
the rest can be in any order.
>Then we change the meaning of OX_OBJS, and instead of saying
>
> ALL_O = $(OX_OBJS) $(O_OBJS)
>
>we just say
>
> ALL_O = $(O_OBJS)
>
>and the meaning of $OX_OBJS is the _subset_ of object file that have
>SYMTAB objects.
We do not have an automatic way of detecting SYMTAB objects, OX_OBJS is
the only way that 2.4 kbuild can tell if an source has SYMTAB or not.
I could change Rules.make to grep the sources and work out what the
flags should be but that is messy and affects all of 2.4 kbuild.
>This should all work pretty much as-is, with som every simple
>modifications to existing old-style Makefiles, and with some even simpler
>modifications to the new-style ones. In fact, it should remove pretty much
>all the ugly games that new-style files do.
Let me get this straight. I provide a minimal patch that helps
document link order, is compatible with kbuild 2.5 and only affects
usb. But you want me to change the meaning of OX_OBJS, add grep to
Rules.make, edit all the old style Makefiles, change all the
bolierplate code in new style makefiles, in short to hit all of 2.4
kbuild. Why?
>And it should make all this FIRST/LAST object file mockery a total
>non-issue, because the whole concept turns out to be completely
>unnecessary.
Only if you think that documentation is unncessary.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 21:00:28 EST