[lkml]   [2000]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: test10-pre7

    [Russell King]
    > Since someone kindly enlightened me that LINK_FIRST was unsorted, I'm
    > finding it very hard to grasp what the difference is between an
    > unsorted LINK_FIRST and unsorted LINK_LAST list, and an unsorted
    > obj-y list. From what I understand, obj-y = $(LINK_FIRST)
    > $(LINK_LAST) ?

    Not quite. If that's how you understand it, I see why you think it's a
    bad idea. Here's what is *really* happening:

    obj-y = {subset of LINK_FIRST that is in obj-y} \
    {subset of obj-y that is not in LINK_FIRST or LINK_LAST} \
    {subset of LINK_LAST that is in obj-y}

    GNU make has extensions that make this easy to implement -- no more
    verbose than the pseudocode, in fact.

    The biggest difference between LINK_FIRST and obj-y is that LINK_FIRST
    is meant to be a static list, not dependent on CONFIG_*, and specifies
    *only* those objects which must be linked before (or after, for
    LINK_LAST) other objects. In the common case, most object files do
    *not* appear in LINK_FIRST or LINK_LAST, but just in O_OBJS.

    In the pathological case of strict requirements for the whole
    directory, LINK_FIRST would contain all of obj-y. Keith and I think
    this is a rare case -- a more common case is the opposite:
    LINK_FIRST/LAST are empty because there are *no* ordering requirements.

    Again, anything that appears in O_OBJS but not in LINK_FIRST is linked
    in arbitrary order. Anything that appears in LINK_FIRST but not in
    O_OBJS is ignored. That is why it can be a static list.

    Since LINK_FIRST is a (usually short) static list, it is easy for the
    author to guarantee that it has no duplicate files in it. By contrast,
    O_OBJS (or obj-y) frequently has duplicates, because of things like

    obj-$(CONFIG_FOO) := foo.o xxx.o
    obj-$(CONFIG_BAR) := bar.o xxx.o

    where xxx.o is something like 8390 support for network cards.

    Removing duplicates is a side effect of the GNU make 'sort' function,
    which is THE ONLY REASON we want to sort $(O_OBJS). The reordering is
    the "other" side effect, the less desirable one. GNU make does not
    provide a 'uniq-without-sort' function, and while one is trivial to
    write in e.g. shell, some of us consider a shell hack to be, well, more
    hackish than LINK_FIRST.

    ** BTW, the only reason I'm still posting to this thread, which seems
    pretty moot because "Linus Has Spoken", is that I believe there is
    still a lot of misunderstanding about what LINK_FIRST actually does.
    When I'm satisfied that the opponents truly *understand* LINK_FIRST
    and still oppose it, I'll shut up.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:45    [W:3.214 / U:0.080 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site