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


    On Tue, 31 Oct 2000, Peter Samuelson wrote:
    >
    > The thing that Keith's patch does is flush these things out into the
    > open. By using LINK_FIRST/LINK_LAST, we declare that "these are the
    > known issues" -- and then the rest of the objects are reordered, and if
    > something breaks, we track it down and add it to LINK_FIRST.

    But it doesn't even WORK.

    You need to have

    LINK_FIRST1
    LINK_FIRST2
    LINK_FIRST3
    ...

    etc to get the proper ordering.

    USB is the _easy_ case. There happen sto be only one file that cares about
    ordering.

    In many other cases, like SCSI, we need almost _total_ ordering. For such
    a case, theer is no "first" or "last" - there is a well-specific ORDER.

    Do you see the problem now? LINK_FIRST/LINK_LAST is a complete and utter
    hack, and it WON'T EVER WORK. The only way it would work is to make
    LINK_FIRST maintain the order, but once you do that LINK_FIRST is
    completely superfluous, as it ends up being exactly the same as $(obj-y).

    See the fallacy? LINK_FIRST doesn't solve anything, because in the end it
    has to do everything O_OBJS will have to do anyway: maintain the full
    order.

    So trust me, LINK_FIRST/LINK_LAST is not going to happen.

    > A few months ago I actually tried to write a make function (yes, GNU
    > make has these!) to remove duplicates while not sorting, but GNU make
    > doesn't seem to support the necessary iteration/(tail-)recursion
    > features. (Surprising, considering GNU's overall LISP-ish worldview.)

    Ehh..

    There are multiple solutions to this. One is to simply not do that then.
    We've done that before, it's not all that painful at all. The classic
    example is the current drivers/net/ Makefile, which is badly written
    anyway (a mixture of old-style and new-style stuff), and has that 8390.o
    and slhc.o multiple thing. It's not that hard to re-write by just adding a
    special

    obj-8390-$(CONFIG_xxx) = y

    for every config that wants 8390.o (and same thing for slhc) and at the
    very end do a final

    obj-$(obj-8390-y) += 8390.o

    Not as simple as what we have now, but not a disaster like the current
    lack of ordering is.

    And if you really want to remove duplicates, at worst we can even use an
    external program for it - which would solve all these things once and for
    all. The difference between

    $(filter .. black magic lies here ..)

    and

    $(shell .. black magic lies here ..)

    is not that big.

    Linus

    -
    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/

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