Permalink
Commits on Oct 14, 2012
Commits on Oct 8, 2012
Commits on Oct 7, 2012
  1. Support 0compile build --shell on Windows

    dabrahams authored and talex5 committed Oct 7, 2012
    Need to use the cmd shell and a more portable method of finding executables in the PATH
Commits on Oct 6, 2012
Commits on Aug 27, 2012
  1. Updated unit-tests

    talex5 committed Aug 27, 2012
Commits on Aug 25, 2012
  1. Switched to new bug reporting URL

    talex5 committed Aug 25, 2012
    Previous one no longer works.
Commits on Aug 4, 2012
  1. Release 0.31

    talex5 committed Aug 4, 2012
  2. Depend on 0install >= 1.10 to get sha256new support

    talex5 committed Aug 4, 2012
    This allows programs that need sha256new to ensure support with:
    
      <implementation ... compile:min-version='0.31'>
Commits on Jul 12, 2012
  1. Can't delete current directory on Windows, so move to parent first

    talex5 committed Jul 12, 2012
    Reported by Dave Abrahams.
Commits on Jun 29, 2012
  1. Don't warn the user if Plash isn't found

    talex5 committed Jun 29, 2012
    Plash seems to be unmaintained now.
  2. Release 0.30

    talex5 committed Jun 29, 2012
  3. Update site-packages atomically

    talex5 committed Jun 29, 2012
    A site-package either exists as a valid complete implementation, or doesn't
    exist. No half-deleted / half-copied version will be found by 0install.
Commits on Jun 28, 2012
Commits on Jun 24, 2012
  1. Name the generated feed "0install.net/feed.xml", not "0install.net/NA…

    talex5 committed Jun 21, 2012
    …ME.xml"
    
    Makes it easier for automated tools to find it.
Commits on Jun 9, 2012
  1. Less verbose test output

    talex5 committed Jun 9, 2012
Commits on May 26, 2012
  1. Don't try to fix up PKG_CONFIG_PATH for native -dev packages

    talex5 committed May 26, 2012
    Would crash in correct_for_64bit.
Commits on May 12, 2012
  1. When autocompiling, get the top-level interface from the feed

    talex5 committed May 12, 2012
    This is so that autocompiling a local feed registers against the
    real interface (which is probably what you wanted), but autocompiling a
    dependency on a local feed registers against the local interface (which
    is the only thing that makes sense).
  2. Fixed autocompile for <runner> dependencies

    talex5 committed May 12, 2012
    We assumed that the new binary wouldn't have any commands, and so didn't
    select it. Now we add dummy commands based on the binary template.
  3. Removed left-over debug output

    talex5 committed May 12, 2012
  4. Release 0.29

    talex5 committed May 12, 2012
Commits on May 7, 2012
  1. Fixed feed names for autocompile

    talex5 committed May 7, 2012
    Same fix as in 96d4122.
  2. Fixed autocompile on 64-bit machines

    talex5 committed May 7, 2012
    Was broken by 50a517b, which added an extra value to the end of uname.
    This caused autocompile to think that the host was always 32-bit, and therefore
    incompatible with the 64-bit binaries that it itself created.
    
    Reported by Dave Abrahams.
  3. Fixed registering of local feeds with autocompile

    talex5 committed May 7, 2012
    Register the new autocompiled implementation against the interface we wanted to
    build, which is not necessarily the one in the <feed-for>.
Commits on May 2, 2012