Each toolchain with their file
Harald Sitter
sitter.harald at gmail.com
Wed Nov 4 14:52:04 UTC 2015
On Fri, Oct 30, 2015 at 7:49 PM, Maximiliano Curia <maxy at debian.org> wrote:
> ¡Hola Aleix!
>
> El 2015-10-30 a las 18:26 +0100, Aleix Pol escribió:
>>
>> On Thu, Oct 29, 2015 at 1:36 PM, Aleix Pol <aleixpol at kde.org> wrote:
>>>
>>> On Thu, Oct 29, 2015 at 12:39 PM, Maximiliano Curia <maxy at debian.org>
>>> wrote:
>>>>
>>>> I would like to hear some feedback about this approach anyway.
>>>>
>>>> The plan would be to tag the packages that contain only dev tools (that
>>>> produce an arch independant output) as Multi-Arch: foreign packages, the
>>>> tools can be installed anywhere, but the cmake files that contain full path
>>>> of the tools would need to be installed in a non arch dependant path.
>>>>
>>>> Happy hacking,
>>>
>>>
>>> I don't really see why you want to change that. The KF5_HOST_TOOLING
>>> variable needs to find the file anyway, so we're not going to be able to
>>> skip the look-up specification anyway.
>
>
>> Ping?
>
>
> I was waiting to see if somebody else had an opinion about this.
>
> Setting the KF5_HOST_TOOLING should work even if the package is Multi-Arch:
> same, you'll end up with a bin-dev installed for each arch, but that
> shouldn't be an issue. So that is another valid option.
FTR:
I think the primary motivation is to have cmake decide (or coerced)
into which host tooling is appropriate rather than have the packaging
coerce cmake (if the paths weren't arch specific cmake would have no
option but to use what is present). Former allows for more "smarts" to
be applied to allow controlled cross-compiling and moves the decision
what is compatible out of the packaging and into cmake.
At any rate, the ideal end result is to have frameworks install
everything related to development to architectured directories. So the
-devs ultimately become MA:same and can contain the build time tools
needed for their arch. At runtime cmake can then decide which of the
available tools to pick depending on the architecture it is building
on (or what the cmake toolchain file tells it to use).
HS
More information about the kubuntu-devel
mailing list