Hi Ricardo, Ricardo Wurmus <rek...@elephly.net> writes:
> Mark H Weaver <m...@netris.org> writes: > >>>> Also, looking ahead, I think it would be great if we could eventually >>>> move to a model where the tests of some packages are split off into >>>> separate derivations. Similarly, we could work toward splitting off >>>> documentation generation to separate derivation for selected packages. >>>> The most important advantage to this approach is that it would allow >>>> inputs needed only for tests or docs to be omitted from the inputs of >>>> the main package. I expect that this will in many cases be needed to >>>> prevent circular dependencies, and it could also greatly reduce the >>>> amount of rebuilding needed after updating certain packages. >>> >>> Currently if test fails, the whole derivation fails, and you can’t >>> install your package. If tests were run separately, this would no >>> longer hold: you could get your package regardless of whether tests >>> fail. >> >> Indeed, and I agree that we would need to address this. >> >>> How would you address this? I guess that calls for a new build >>> model, no? >> >> I'm not sure what you mean by "build model", whether you are talking >> about the daemon interface or something else, but I think the changes >> could be confined to the Guix user interface. A field could be added to >> <package>, somewhat similar to 'replacement', but pointing to a package >> object which runs tests, or perhaps a list of package objects. The guix >> client could simply add the test packages to the list of derivations to >> build. This could be inhibited via a "--no-tests" guix build option. > > A problem that would need solving is that tests often depend on the > build directory, which is different from what is installed (and ends up > in the store). The build directory is lost. I suggested a solution to this problem in my paragraph immediately following the one you quoted above. Did you see it? Here it is again: In typical cases where "make check" expects to be run from a fully built source directory, the main package would typically produce a tarball of the built source directory as an additional output. The test package would simply unpack this tarball and run "make check" in it. Mark