On Wed, Sep 14, 2016 at 12:05:15PM +0200, Stephen Kelly via Development wrote:
> I want to understand Qbs and what it can do with a dynamic build graph
> which CMake can't do.
>
there is no such thing, as after full expansion the graph has to be
static by definition (the output artifacts are expect
> On Sep 14, 2016, at 12:46 AM, Lars Knoll wrote:
>
> That’s the policy we have had all the time. No feature removal or additions,
> no API changes in patch level releases.
>
> If a feature is really unused, or causes larger issues one can of course
> discuss exceptions, but it should be a c
> On 14 Sep 2016, at 15:45, Frederik Gladhorn wrote:
>
> On fredag 9. september 2016 12.04.57 CEST Kimmo Ollila wrote:
>> Hi All,
>>
>> We are planning to open new Boot2Qt Device Utilities module repository.
>> Qt Device Utilities module allows user manipulate easily various embedded
>> device
On fredag 9. september 2016 12.04.57 CEST Kimmo Ollila wrote:
> Hi All,
>
> We are planning to open new Boot2Qt Device Utilities module repository.
> Qt Device Utilities module allows user manipulate easily various embedded
> device settings via simple QML APIs.
>
> More information can be found
13.09.2016, 23:00, "Stephen Kelly" :
> Konstantin Tokarev wrote:
>
>>> -Qbs has great features that you can't find in other build systems (e.g.
>>> it can build multiple ABIs/platforms at once).
>>
>> For the record, premake can do it as well.
>
> Can you show me the syntax for this with prema
On 13/09/16 22:29, Christian Kandeler wrote:
Stephen Kelly wrote:
There is no input file. There is only an input number. The task is from
Bo, who gave it as a simplified example.
Oops, I'm wrong here. Bo said to read the number from a file.
I don't think that changes anything though regarding
> On 13 Sep 2016, at 20:41, Jake Petroules wrote:
>
>
>> On Sep 13, 2016, at 11:40 AM, Konstantin Tokarev wrote:
>>
>>
>>
>> 13.09.2016, 21:33, "Jake Petroules" :
>>> Because the APIs are deprecated by Apple so they would have had to be
>>> removed/changed soon anyways, especially when an
That’s the policy we have had all the time. No feature removal or additions, no
API changes in patch level releases.
If a feature is really unused, or causes larger issues one can of course
discuss exceptions, but it should be a conscious decision involving the
relevant maintainers.
Cheers,
L
Should we have a “no feature removal for cleanup reasons in patch
releases” policy? That’s easy to understand for everyone and we
don’t have to make the "is it obscure enough” judgement.
(The build failure could have been easily fixed so I don’t see
it as a relevant reason.)
Morten
> On 13 Sep
