Re: [Zero-install-devel] auto compilation

[Thomas L. <ta...@gm...>]

On 24 August 2014 21:47, Thomas Leonard <ta...@gm...> wrote:
> On 17 August 2014 01:57, Tim Cuthbertson <ti...@gf...> wrote:
>>
>>
>>
>> On Sat, Aug 16, 2014 at 6:45 PM, Thomas Leonard <ta...@gm...> wrote:
>>>
>>> On 16 August 2014 09:30, Tim Cuthbertson <ti...@gf...> wrote:
>>> >
>>> >
>>> >
>>> > On Thu, Aug 14, 2014 at 10:18 PM, Thomas Leonard <ta...@gm...>
>>> > wrote:
>>> >>
>>> >> On 14 August 2014 11:40, Tim Cuthbertson <ti...@gf...> wrote:
>>> >> > On Thu, Aug 14, 2014 at 7:12 PM, Thomas Leonard <ta...@gm...>
>>> >> > wrote:
>>> >> >> On 14 August 2014 09:19, Tim Cuthbertson <ti...@gf...> wrote:
>>> >> >>> On Sun, Aug 10, 2014 at 9:17 PM, Thomas Leonard <ta...@gm...>
>>> >> >>> wrote:
>>> >> >>>> On 9 August 2014 14:28, Tim Cuthbertson <ti...@gf...> wrote:
>>> >> >>>>> I've had this on the back-burner for a while, but I'm still very
>>> >> >>>>> excited about this feature and I've finally got some functioning
>>> >> >>>>> patches!
>>> >> >>>>>
>>> >> >>>>> 0install: https://github.com/gfxmonk/0install/compare/autocompile
>>> >> >>>>>
>>> >> >>>>> 0compile: https://github.com/gfxmonk/0compile/commits/autocompile
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>> == How it works: ==
>>> >> >>>>>
>>> >> >>>>> When --autocompile is given (I believe strongly that this should
>>> >> >>>>> be
>>> >> >>>>> the default, as it is in this patch), the solver generates a
>>> >> >>>>> synthetic
>>> >> >>>>> implementation based off the embedded <compile:implementation> in
>>> >> >>>>> each
>>> >> >>>>> source implementation's `compile` command.
> [...]
>>> > I thought about moving the synthetic implementation generation from
>>> > feed.ml
>>> > into impl_provider, which seems nicer (because it avoids the `lazy` hack
>>> > I'm
>>> > using in the impl_mode type), but currently feed.ml doesn't expose
>>> > enough
>>> > functionality to be able to parse the embedded <compile:implementation>.
>>> > This seems quite embedded with the feed parsing logic, so I wasn't sure
>>> > whether that was worth trying to expose to other modules, but I'd
>>> > appreciate
>>> > advice on this.
>>>
>>> What functions are you missing? I think a couple more got exposed by
>>> the split into impl.ml, but more could be added.
>>
>>
>>
>> Ahh yeah, I still hadn't looked at rebasing this thing. But I just took a
>> look, and I think it's still not exposed.
>>
>> What I need to do is grab the Qdom.element corresponding to the compile
>> command's <compile:implementation> and parse it as if it were a single
>> <implementation> in the feed (using the attrs and retrieval methods from the
>> original source). My original code uses process_group_elem, which is only in
>> scope within feed.ml#parse_implementations (relevant code:
>> https://github.com/gfxmonk/0install/commit/7cffa2eff9f54ef7af44beefb7d67f3c4118a61b#diff-e386caf1b15d64190356836803e1ac3aR460)
>>
>> I've rebased / reworked slightly now, and got it working again:
>>
>> https://github.com/gfxmonk/0install/commits/autocompile-v3
>
> I had a go at using a `binary_of impl_type rather than adding a separate mode:
>
>   https://github.com/0install/0install/commit/f5319f9243c7f32f9d4f0fc284b3d22f795a2432#diff-d41d8cd98f00b204e9800998ecf8427e
>
> (it's on top of your patch, so part of it is just reverting some of
> those changes)

A cleaned-up version that applies directly to master is here:

  https://github.com/0install/0install/commits/autocompile

With the new Impl.existing_source function, this requries very few
changes to the rest of the code.


-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA