1. 20 9月, 2009 1 次提交
  2. 15 6月, 2009 1 次提交
  3. 03 5月, 2007 1 次提交
  4. 02 4月, 2007 1 次提交
    • J
      [PATCH] kbuild: fix dependency generation · c21b1e4d
      Jan Beulich 提交于
      Commit 2e3646e5 changed the way the
      split config tree is built, but failed to also adjust fixdep accordingly
      - if changing a config option from or to m, files referencing the
      respective CONFIG_..._MODULE (but not the corresponding CONFIG_...)
      didn't get rebuilt.
      
      The problem is that trisate symbol are represent with three different
      symbols:
          SYMBOL=n => no symbol defined
          SYMBOL=y => CONFIG_SYMBOL defined to '1'
          SYMBOL=m => CONFIG_SYMBOL_MODULE defined to '1'
      
      But conf_split_config do not distingush between the =y and =m case, so
      only the =y case is honoured.
      
      This is fixed in fixdep so when a CONFIG symbol with _MODULE is found we
      skip that part and only look for the CONFIG_SYMBOL version.
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c21b1e4d
  5. 19 2月, 2006 1 次提交
    • J
      kbuild: consolidate command line escaping · 6176aa9a
      Jan Beulich 提交于
      While the recent change to also escape # symbols when storing C-file
      compilation command lines was helpful, it should be in effect for all
      command lines, as much as the dollar escaping should be in effect for
      C-source compilation commands. Additionally, for better readability and
      maintenance, consolidating all the escaping (single quotes, dollars,
      and now sharps) was also desirable.
      Signed-Off-By: NJan Beulich <jbeulich@novell.com>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      6176aa9a
  6. 26 12月, 2005 1 次提交
  7. 26 6月, 2005 1 次提交
  8. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4