[Buildroot] [PATCH v4 2/6] qt5: Provide generic qmake package infrastructure

Andreas Naumann dev at andin.de
Thu Mar 28 09:50:52 UTC 2019



Am 28.03.19 um 09:58 schrieb Arnout Vandecappelle:
> 
> 
> On 27/03/2019 23:10, Andreas Naumann wrote:
>> 
>> 
>> Am 26.03.19 um 11:09 schrieb Arnout Vandecappelle:
>>> 
>>> 
>>> On 26/03/2019 08:18, Thomas Petazzoni wrote:
>>>> Hello,
>>>> 
>>>> On Tue, 26 Mar 2019 00:16:47 +0100 Arnout Vandecappelle 
>>>> <arnout at mind.be> wrote:
>>>> 
>>>>>> This is done by re-running the install step of the qmake 
>>>>>> generated Makefile with the package build directory
>>>>>> prepended (to the staging/host path). Even though this does
>>>>>> create lengthy pathes it allows for easy separation of the
>>>>>> staging files from the host destined files by just omitting
>>>>>> the resulting BUILD_DIR+HOST_DIR path from the following
>>>>>> rsync call to the real target folder.
>>>>> 
>>>>> We have not converged yet on whether this is the right
>>>>> approach. So maybe, in order to move forward, it would be
>>>>> better to split the patch up into a first bit that creates
>>>>> the qmake package but does not define target install steps,
>>>>> then convert the relevant packages to qmake packages, and
>>>>> finally change the qmake infra to do target install and
>>>>> changes all the packages again. It's more work to do it this
>>>>> way, obviously, but it would allow us to already commit part
>>>>> of the series before we have converged on it completely.
>>>> 
>>>> While I understand your idea of splitting things up further in 
>>>> terms of patches, I think we can try to agree on how the
>>>> target installation step should be done and use the approach
>>>> proposed by Andreas to
>>> 
>>> Sure, that's why I said "maybe". It's not a requirement, but it
>>> is also frustrating to respinning a series and seeing no progress
>>> on it. That's why I proposed the option.
>> 
>> Splitting the conversion of each package (and doing this one
>> package at a time?) really seems like a lot work and I dont know if
>> it leads to a nicer history. I propose to split up the infra
>> introduction in two parts (config,build,staging vs target install),
>> but keep the conversion of each package in one patch. Or maybe one
>> patch for the straightforward cases and the rest individually?
> 
> Sounds good to me. As Thomas wrote: you don't have to do it if it's
> too much work.
> 
> IIUC your proposal would be:
> 
> 1. Basic qmake infra 2. Convert all packages to qmake infra (trivial
> because the difficult cases still use custom staging/target install
> commands, you just don't remove them). 3. Add target install support
> to qmake infra 4. Convert all easy packages to target install from
> qmake infra (i.e. just remove the target install commands) 5-N.
> Convert difficult packages.
> 

Actually I meant to not do step 2, but this should be doable as well.
I'll see how it goes.

> I repeat: it would be nicer this way, but if it's take too much time
> to do it, we'll accept it as just two or three patches as well.
> 
> [snip]
>>>>> However, I'm not sure that this is the way we want to go.
>>>>> What is wrong with the pkg-files-list? You said before that
>>>>> it was incorrect, but if that is the case, it should be
>>>>> fixed.
>> 
>> pkg-files-list currently breaks the parallel build. I did send a
>> patch for that. However I suspect the lists might still not be
>> correct because if a package provides a file which already exists
>> it wont be recorded, right?
> 
> It will be recorded twice in that case. And the check-uniq-files
> script checks in the finalize step that this doesn't actually
> happen.

oh i see. I didnt fully understand step_pkg_size_inner.

> 
>> This situation is problematic anyway but currently solved by at
>> least a deterministic package build/install order in which "the
>> last wins". Using the staging pkg-files-list for target install
>> would reverse that to "first package wins". Finally, when building
>> in parallel, this will become a real issue.
> 
> Yes and no. It's not an issue because each package installs in its
> own host/staging/target dirs. It may become an issue when combining
> these dirs from different packages, but that combination is still
> deterministic (it is not done in parallel and the order is fixed with
> sort).

True. Thanks for pointing out.


regards,
Andreas

> 
> But since we agreed to tmpinstall anyway, the point is moot.
> 
> Regards, Arnout
> 
> 
> [snip]
> 



More information about the buildroot mailing list