l...@gnu.org (Ludovic Courtès) writes:
> Done in 645b9df858683dc05ffa04c9eb2fdc45ccef4a65. Feedback welcome!
>
> Ludo’.
Excellent! I will try to use this in the future, and see how well it
works for my use case.
Ricardo Wurmus skribis:
> Ludovic Courtès writes:
>
>> Ricardo Wurmus skribis:
>>
>>> Ludovic Courtès writes:
>>>
Again to make this more convenient, I thought we could have a
--with-graft option, which would work like --with-input except that it
would graft the new Z onto A/B/C
Ludovic Courtès writes:
> Ricardo Wurmus skribis:
>
>> Ludovic Courtès writes:
>>
>>> Again to make this more convenient, I thought we could have a
>>> --with-graft option, which would work like --with-input except that it
>>> would graft the new Z onto A/B/C instead of rebuilding them.
>>
>>
Ricardo Wurmus skribis:
> Ludovic Courtès writes:
>
>> Again to make this more convenient, I thought we could have a
>> --with-graft option, which would work like --with-input except that it
>> would graft the new Z onto A/B/C instead of rebuilding them.
>
> This is a good idea!
Done in 645b9df
Ludovic Courtès writes:
> Again to make this more convenient, I thought we could have a
> --with-graft option, which would work like --with-input except that it
> would graft the new Z onto A/B/C instead of rebuilding them.
This is a good idea!
~~ Ricardo
l...@gnu.org (Ludovic Courtès) writes:
> sba...@catern.com skribis:
>> - Currently every dependency is located at a well known globally unique
>> and globally meaningful path; add some kind of "variant package"
>> construct which specifies a package which is "passed in" to the
>> environment
Hello!
sba...@catern.com skribis:
> When I am hacking on some library Z, I continuously want to test the
> effects that my changes to Z have on packages A/B/C which depend on
> Z. The same applies, in general, when hacking on any package Z which
> other packages A/B/C depend on: While developing,
