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

Arnout Vandecappelle arnout at mind.be
Thu Mar 28 08:58:43 UTC 2019



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.

 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.

> 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).

 But since we agreed to tmpinstall anyway, the point is moot.

 Regards,
 Arnout


[snip]


More information about the buildroot mailing list