On Thu, Jan 04, 2024 at 11:35:45AM +, Edward Welbourne via Development
wrote:
Volker Hilsheimer (8 December 2023 23:55) wrote (inter alia):
Would it make a huge difference if we didn’t require perl (and IIRC
we only need it for the init-repository script)?
Our post-commit hook also
On Tue, Oct 31, 2023 at 10:33:27PM +0100, Arno Rehn wrote:
On 24.10.23 21:12, Arno Rehn wrote:
On 22.10.23 20:57, Andy Nichols wrote:
Ideally if QtGamepad is reintroduced in Qt6 it would be with some
flavor of these changes rather than just being a strait port form Qt 5.
Agreed. Maybe I'll
On Wed, Mar 08, 2023 at 10:16:08AM +, Marc Mutz via Development wrote:
Did my first conscious ldd on QtCore todays and just found it curious
that it linked against pcre and pcre2-16.
I assume they live in different "namespaces" and so it's ok to link
both?
yes, you can verify that
On Fri, Sep 02, 2022 at 02:15:15PM +, Volker Hilsheimer wrote:
+1 to go ahead with QtPythonScripting as the name and repository.
how about QtPyScript? that's not so long, and makes the parallel to
QtScript very obvious.
___
Development mailing
On Mon, Jun 27, 2022 at 11:40:15AM +, Ivan Solovev wrote:
So, if we split network now, we will need to care about manually
picking to 6.4, 6.3, 6.2 and 5.15.
or just make the bot recognize a syntax like `qtbase(6.4 6.3 6.2 5.15)`?
fwiw, qtrepotools//bin/git-qt-cherry-pick should be
On Sat, Mar 26, 2022 at 08:12:31AM -0300, Thiago Macieira wrote:
On Saturday, 26 March 2022 04:57:08 -03 Oswald Buddenhagen wrote:
(it would be nearly trivial to implement now - just use git-gpick.)
There are also cases when changes in the middle of a series have been
integrated
On Fri, Mar 25, 2022 at 09:39:27PM -0300, Thiago Macieira wrote:
When you have multiple changes you've submitted, you could pre-check
the last one and get a result for all of them. That use-case will go
away with rebasing.
nobody said that dependencies would be ignored.
But that was already
On Fri, Feb 11, 2022 at 11:04:25PM -0800, Thiago Macieira wrote:
(I don't think qtbase is the right place for this)
yeah, probably somewhere in qtqa/.
I'd like to propose we use Git notes to include information into
commits about successful cherry-picks.
yay, i've been arguing for that
On Mon, Nov 22, 2021 at 10:43:45AM +, Edward Welbourne wrote:
Documenting it while it's fresh in
your mind generally leads to a better description, after all,
i'm not so sure about that. as seen by the quality of the [ChangeLog]
entries (in as far as present at all), many people have
On Fri, Nov 19, 2021 at 03:11:57PM +, Kai Koehne wrote:
Can we agree to document new features in Qt 6.3 and following released
directly in qtdoc.git?
won't this cause conflict hell during release finalization? the
turnaround time for submitting patches is still quite unreasonable for
On Fri, Oct 29, 2021 at 07:53:56AM +, Lars Knoll wrote:
This result means that the Qt Project doesn’t have confidence in Ossi
[...]
i would like to thank the few people who don't mistake sloppiness and
short-sightedness for pragmatism, understand that it's appropriate to
resist abusive
On Wed, Oct 20, 2021 at 07:37:37AM +, Lars Knoll wrote:
Please see
https://lists.qt-project.org/pipermail/development/2021-October/041840.html,
where I proposed a 7 days voting period. This wasn’t contested by
anybody.
and? what would be the harm in changing things now? it's not like the
hello jury,
On Tue, Oct 19, 2021 at 07:57:39AM +, Lars Knoll wrote:
I’d like to urge everybody who is going to cast a vote to [...]
as lars' mail sadly doesn't provide any actual guidance what exactly
you're supposed to base your vote on, here's my own stab at it:
you need to decide
-
On Thu, Sep 16, 2021 at 07:52:14AM +, Lars Knoll wrote:
The original problem is that using a -2 to block a change that has been
approved by the module maintainer is basically abusing gerrit to break
our governance model.
telling the maintainer to not do a proper job as a maintainer is also
On Thu, Sep 16, 2021 at 12:40:37AM +0300, Иван Комиссаров wrote:
15 сент. 2021 г., в 14:03, Oswald Buddenhagen
написал(а):
for example, he plainly admits that his documentation doesn't match
the code.
That’s not true.
for it not being true you're making a _remarkable_ effort to establish
On Wed, Sep 15, 2021 at 01:37:38PM +0200, Christian Kandeler wrote:
I think our definition of "guidance" differs. For me, it does not
involve going into infinite loops of obsessively arguing about points
that only I care about. I do believe, however, that I am reasonably
capable of telling a
On Tue, Sep 14, 2021 at 02:33:04PM +, Lars Knoll wrote:
Ossi, I (and probably others on this mailing list) would also like to hear your
view on this.
my view is that ivan is being unreasonable (surprise surprise).
most of the recent discussion happened on discord
On Mon, Sep 13, 2021 at 09:56:23AM +0200, Ulf Hermann wrote:
However, if we nail down the meaning of @"string" to "create and
resolve a URL", then we cannot use a plain '@' for much else.
it would be kinda logical for @ applied to a structure to mean resolving
all urls inside it, which would
On 12 Jul 2021, at 21:19, Thiago Macieira
wrote:
So a full history import MAY have negligible marginal impact over a
squashed import (.git is compressed).
that might be the case.
but the point remains that the history that didn't exist along the
merged mainline would live elsewhere (unless
On Mon, Jul 12, 2021 at 02:17:01PM +, Tor Arne Vestbø wrote:
One way to do this is with a prefixed subtree merge without squashing the
history of controls2.
What ossi (?) referred to was using git replace to inject the history of
controls, but I’m not sure how that would look so perhaps
On Thu, May 13, 2021 at 08:35:37PM +, Eike Hein wrote:
May 13, 2021 9:59 PM, "Oswald Buddenhagen" wrote:
what would interest me is why you chose to host this on your own
infrastructure instead of publicly demanding that tqtc plays by the
rules and hosts the fork on qt project in
On Thu, May 13, 2021 at 04:39:54PM +, Eike Hein wrote:
To make this work in general we were in a conversation with the Qt
Company before announcing the tree, to let them know that this is
happening and why, and so the Qt Company could confirm it would be
doing the patch reviews to make
the owner) than accurate line
numbers.
Oswald Buddenhagen (1 March 2021 17:02) replied:
you mean actual git merges, rather than rebases/cherry-picks? that
will lead to a completely insane history in busy repositories.
I'm a bit curious about that one myself; but it can perfectly well
On Mon, Mar 01, 2021 at 01:25:50PM +, Lars Knoll wrote:
First of all, you can now find a ‘Precheck' button in gerrit. That
button triggers a full CI test run of the Sha1 in the change and will
post back the result of that run as a comment.
so this simply exposes the pre-existing
On Sat, Feb 06, 2021 at 08:19:46AM +0800, taotieren wrote:
I want to update the simplified Chinese translation for qt-creator,
what should I do?
https://wiki.qt.io/Qt_Localization
___
Development mailing list
Development@qt-project.org
On Thu, Jan 28, 2021 at 04:48:31PM +, Volker Hilsheimer wrote:
On 22 Jan 2021, at 12:39, Oswald Buddenhagen wrote:
remember that this is only for the commits that explicitly ask for a dep
update, and they currently do that by modifying the yaml file.
So things either work, or they need
On Thu, Jan 21, 2021 at 04:06:03PM +, Volker Hilsheimer wrote:
Am 17.09.19 um 14:27 schrieb Oswald Buddenhagen:
for example, the information that a build with updated dependencies
is required can be stored as an annotation in the commit message
(that's exactly what zuul does, afaik
On Fri, Jan 15, 2021 at 10:19:56AM +, Volker Hilsheimer wrote:
On 14 Jan 2021, at 23:23, Oswald Buddenhagen wrote:
I must have missed that. Could you share your idea again, it sounds
great.
https://lists.qt-project.org/pipermail/development/2019-September/037465.html
FWIW, I know it’s
On Thu, Jan 14, 2021 at 02:08:43PM +, Volker Hilsheimer wrote:
Nevertheless, federating the declaration of the dependencies across
modules out to each module is the right idea, I think.
no, it's not. for tightly bound co-evolving packages, the vcs should
provide as much atomicity as
On Mon, Jan 04, 2021 at 07:55:10PM +, Volker Hilsheimer wrote:
It seems that releasing a 6.0 was the best way to get more eyes and
brains on Qt 6.
one can always say that, but there is a balance to be struck, and it is
*very* obvious that 6.1 will be what and when 6.0 should have been.
On Mon, Jan 04, 2021 at 10:55:03AM +, Tuukka Turunen wrote:
With Qt 6.0.0 released and the first patch release (Qt 6.0.1) coming
soon, it is time to enter the commercial-only LTS phase for Qt 5.15
LTS.
that's some brilliant timing, given that no actual qt 6 release even
exists yet.
On Tue, Nov 03, 2020 at 10:34:29AM +, Alex Blasche wrote:
After all the trinity of quality - time - resources must be adhered to.
indeed, but you're still failing to draw the obvious conclusion. ;)
"priority inflation" is a "natural" effect of an issue tracker drowning
in unresolved
On Tue, Nov 03, 2020 at 12:00:27AM +1000, Jason McDonald wrote:
Is there some obscure reason behind the duplicate resolution or is it a
mistake as I suspect?
certainly a mistake.
note that "Fixed" is redundant with "Done", and was introduced as an
unintended side effect of migrating issues
On Mon, Nov 02, 2020 at 08:01:13AM -0800, Thiago Macieira wrote:
On Monday, 2 November 2020 05:24:45 PST Jason McDonald wrote:
There may be such a tool, but if there is it presumably isn't functioning
anymore (unless it's definition of "too long" is more than two years).
I think it was
On Mon, Nov 02, 2020 at 10:26:31AM +, Shawn Rutledge wrote:
[stuff about changelogs]
for completeness:
some of your points re-iterate what has already been said in
https://bugreports.qt.io/browse/QTQAINFRA-1960 (which presumably needs a
revision for the now used go program).
and the
On Mon, Jul 20, 2020 at 07:32:41AM -0700, Thiago Macieira wrote:
I am not going to accept a null-pointer dereference in there. The
static_cast(nullptr)-> must go.
this this construct is actually UB is disputed on wikipedia (in the
offsetof article).
anyway, this can be trivially bypassed by
meaningful, afaict.
On Sun, Jul 19, 2020 at 01:20:12PM +0200, Giuseppe D'Angelo via
Development wrote:
Il 19/07/20 12:51, Oswald Buddenhagen ha scritto:
- the compiler becomes intentionally belligerent, in which case an
override switch will be provided as well (if not instantly, then after
On Sat, Jul 18, 2020 at 10:10:41AM -0700, Thiago Macieira wrote:
On Friday, 17 July 2020 23:32:41 PDT Simon Hausmann wrote:
This hack has been in QtQml in production since its release in 2010 (see
static cast selector).
It would be a shame if this stopped working
The problem here is the
On Thu, Jul 16, 2020 at 03:40:35PM +, Volker Hilsheimer wrote:
The struct has no data itself, so ideally would be of size zero. The
moc-implementation redirects to whatever is passed into the
Q_PRIVATE_QPROPERTY macro [...]
if it's all "fake" anyway, what exactly is the point of having
On Fri, May 29, 2020 at 06:30:07AM -0700, Adam Light wrote:
I will note, however, that #including the moc output from the .cpp
file (the "moc_myclass.cpp" form) is not compatible with my mocinclude
trick posted at https://bugreports.qt.io/browse/QTBUG-81348.
the report doesn't mention
On Thu, May 28, 2020 at 08:43:14AM -0700, Adam Light wrote:
[include mocs]
Changing Qt in a way that would require #including the moc output from
the .cpp file might cause noticeable increase in build times unless moc
is also changed.
care to explain how _exactly_ that would be the case?
On Wed, May 27, 2020 at 08:21:48AM +, Fabian Kosmale wrote:
the only way to get this to work is to include the moc file in the
same cpp file. While doing this inside of Qt is possible,
this is not something we can subject our users to.
orly? kde had been doing that for quite a while.
On Fri, May 15, 2020 at 12:49:28PM +, Laszlo Agocs wrote:
Agreed. The choice of which backend (be it a dynamically loaded or
statically linked in one) to use is going to remain a runtime choice.
yes
[...] Building on the Qt plugin system is therefore still very valuable
here,
i don't
On Fri, May 15, 2020 at 09:20:26AM +, Tor Arne Vestbø wrote:
But for the ones that live in qtbase, the majority of their code would
be moved to the relevant modules, leaving only the plugin’s entry point
as a shared library.
having a significant part of the plugin's implementation (if not
On Thu, May 14, 2020 at 06:12:15PM -0700, Thiago Macieira wrote:
That means the string classes, if any, need to be convertible to
QByteArray anyway.
yes, via QTextCodec.
(behind the scenes some friend functions may be used for zero-copy
conversions.)
On Fri, Apr 17, 2020 at 01:31:04PM +, Volker Hilsheimer wrote:
To clarify, we don’t “disable merging”, we turn off the bot. People
with the privilege to push merge commits can in theory continue to do
so forever.
yes, but mixing merges and cherry-picks is, and remains, bad. why do you
moin,
not even six years after the initial announcement, i have landed my
git-gpush improvements and related tools to the qtrepotools repo.
note for early adopters (i heard that there are quite some of you at
kdab): the command lines and metadata storage changed over the years.
the landing
On Tue, Mar 10, 2020 at 02:40:41PM +, Cristian Adam wrote:
What about Pull requests?
before you continue reinventing the wheel, i recommend that you read the
comments on QTPM-314 (yes, all of them). you can open a task for the
public gerrit component if you still feel revolutionary
On Fri, Feb 21, 2020 at 08:29:54AM -0800, Thiago Macieira wrote:
can we deprecate setupChildProcess() in Qt 5.15 and *remove it* in 6.0?
at least, we should. ;)
but let's bikeshed the name of the callback setter, which needs to be
added at the same time -
On Fri, Feb 21, 2020 at 12:49:02PM +0100, Julien Cugnière wrote:
For example, a normal function call could end up emiting a signal, and
as such, any function could be as dangerous as a signal.
indeed, the recursivity of the issue utterly destroys the "safety"
argument.
however, i still like
On Fri, Feb 21, 2020 at 08:23:51AM +, Kai Koehne wrote:
Another alternative is to actually use C++ attributes for this:
[[qt::emit]] somethingChanged();
that's a terrible idea, because it's visually noisy (and correspondingly
bothersome to type).
if anything, i'd go for
#define qEmit
On Wed, Jan 29, 2020 at 11:40:46PM +0100, Filippo Cucchetto wrote:
Maybe you didn't get it but i meant to both put a reasonable price for
a commercial license (500$) and turning everything GPL or commercial.
Making everything GPL forces all LGPL to buy a commercial license. This
obviously
On Tue, Nov 26, 2019 at 02:42:46PM +, Volker Hilsheimer wrote:
but I’d need a practical proposal to replace it with. Do I understand
correctly that you’d rather go “all in”, i.e once we are ready, flip
all branches to “cherry-pick only”?
all-in is one option, yes.
it has the advantage
On Fri, Nov 22, 2019 at 12:25:21PM +, Joerg Bornemann wrote:
On the topic of switching to gettext:
My searches yielded nothing.
because our archives are incomplete and badly indexed, and clearly
nobody bothered to make a jira task (at least a publicly visible one).
It would be cool to
On Fri, Nov 22, 2019 at 04:19:21PM +, Kai Koehne wrote:
Anyhow, QCommandLineParser processes command line arguments from the
outside. These command line arguments might come from other tools,
output ... so it should be really robust in handling these.
"from the outside" is not the
On Thu, Nov 21, 2019 at 04:38:28PM +, Joerg Bornemann wrote:
There is the ongoing effort to replace the old outdated parser with a
clang, similar to what's been done in qdoc. The corresponding JIRA
issue is QTBUG-71835.
a more radical and much simpler approach would be switching to gettext
On Thu, Nov 21, 2019 at 12:13:55PM +, Robert Loehning wrote:
=== Which code needs fuzz testing the most? ===
Agreed criteria: Code that operates on possibly untrusted data
Proposals from the audience:
* Classes
** [https://doc.qt.io/qt-5/qcommandlineparser.html QCommandLineParser]
**
On Thu, Nov 21, 2019 at 08:50:10AM +, Volker Hilsheimer wrote:
== Discussed and Agreed Proposal ==
We start with Qt 5.15/14/12 (ie 5.15 is “dev” in the Qt 5 series), and
continue to merge 5.15 into dev until 5.15 has reached feature freeze.
this has NOT been agreed upon. what actually
On Sun, Oct 20, 2019 at 12:14:29AM +0300, Ville Voutilainen wrote:
On Fri, 18 Oct 2019 at 19:53, Edward Welbourne wrote:
Putting the * or & to the left of the space promotes the lazy reading of
a declaration as being
type name;
which works just fine for the most common cases, but lulls
On Tue, Oct 15, 2019 at 08:38:30AM +, Liang Qi wrote:
2. patch releases, 1st one and others, for the first one, like 5.14.0
perhaps similar story like above. Anyway, for the patch releases, if
the changes missed this release, but still could happen in next. So I
think it’s better to remove
On Mon, Oct 14, 2019 at 01:40:48PM +, Kari Oikarinen wrote:
On 12.10.2019 14.14, Oswald Buddenhagen wrote:
> On Fri, Oct 11, 2019 at 12:04:20PM +, Kari Oikarinen wrote:
>> As far as I can tell, the major motivation for providing this week
>> of
>> soft branchi
On Tue, Oct 15, 2019 at 06:16:33AM +, Kari Oikarinen wrote:
After thinking about it again, I agree with you that it's irrelevant.
There could be a category of changes that would need to wait and I was
describing it.
But in fact there isn't, since the branching and the associated cut-off
has
On Fri, Oct 11, 2019 at 12:04:20PM +, Kari Oikarinen wrote:
I want to propose eliminating soft branching phase and instead use the
creation of the branch as a cut-off for feature freeze (or bug fixes
for a patch release).
(facepalm)
but in case you actually tried to do your homework first
On Thu, Sep 19, 2019 at 07:14:30AM +, Simon Hausmann wrote:
Unfortunately that will not work out of the box :-(. The tests are only
compiled when runinng tests. It is not feasible to run tests on
Integrity for every qtbase integration.
really? the task about that was marked as done just
On Tue, Sep 17, 2019 at 12:39:01PM +, Simon Hausmann wrote:
Am 17.09.19 um 14:27 schrieb Oswald Buddenhagen:
for example, the information that a build with updated dependencies
is required can be stored as an annotation in the commit message
(that's exactly what zuul does, afaik
On Tue, Sep 17, 2019 at 06:56:39AM +, Simon Hausmann wrote:
When the todo list is empty and there are no more pending updates, the
batch update is complete. If during that update there were no failures,
the Qt Module Updater will also push a change to qt5.git with an update
to all
On Tue, Jun 04, 2019 at 06:38:35PM +0200, André Hartmann wrote:
> I just stumbled about the problem, that the new Gerrit removes the
> sanity review vote after a change was moved to a new destination branch.
>
> While it's probably good to remove code review votes on branch change,
> the sanity
On Mon, Jun 03, 2019 at 10:59:59AM -0700, Thiago Macieira wrote:
> It can only read qmake files.
>
nope
> And it lacks the transform functions to produce an hex dump.
>
nope
___
Development mailing list
Development@qt-project.org
On Tue, May 07, 2019 at 01:52:48PM +, Liang Qi wrote:
> This is a very common issue when I do the integraton work in qt5.
>
> For example, currently we have 5.12->5.13->dev merge order, and the last
> round 5.13->5.13.0 today. One change(changeA) had been integrated in 5.13,
> and another
On Sun, Mar 24, 2019 at 01:21:20PM +0100, Allan Sandfeld Jensen wrote:
> Drivers have slowly stopped using many of the hardware acceleration as
> 2D acceleration in many cards have languished and it is often faster
> to do in software, or the hardware accelerated ones are very limited
> types of
On Wed, Feb 27, 2019 at 08:20:43PM +0300, Konstantin Tokarev wrote:
> 27.02.2019, 19:00, "Thiago Macieira" :
> > On Tuesday, 26 February 2019 22:59:12 PST J-P Nurmi wrote:
> >> Is it technically possible to start() and then detach()?
> >
> > No, because the way to start changes. The detached mode
On Wed, Feb 27, 2019 at 07:59:12AM +0100, J-P Nurmi wrote:
> Is it technically possible to start() and then detach()?
>
it wouldn't work particularly well on unix.
___
Development mailing list
Development@qt-project.org
On Fri, Jan 25, 2019 at 01:12:11PM +, Frederik Gladhorn wrote:
> qt5.git serves several purposes today, for example:
> - it contains a few binaries needed for Windows development
>
that's rather trivial, and the only reason i didn't fix it years ago is
that factoring these out to another repo
On Thu, Jan 24, 2019 at 09:13:32AM +, Edward Welbourne wrote:
> A cherry-pick takes the diff involved in one commit and patches another
> check-out with it. A merge uses the digraph of commits in sophisticated
> ways; a cherry-pick does not.
>
uhhh, actually, it does. cherry-pick even has
> > On 15 Jan 2019, at 13:44, Kari Oikarinen wrote:
> >> An alternative way of seeing (and perhaps handling) is in the same way as
> >> we
> >> handle feature branches. The qt6/6/next/whatever branch would be for
> >> development
> >> that can't be put into dev yet as it is not suitable for the
On Wed, Jan 02, 2019 at 07:35:45PM +0200, Aleksey Kontsevich wrote:
> Should I assign this regression to You as well:
> https://bugreports.qt.io/browse/QTBUG-72687?
>
what makes you think that i introduced it?
> 02.01.2019, 18:47, "Oswald Buddenhagen" :
> >
On Wed, Jan 02, 2019 at 02:35:42PM +0200, Bogdan Vatra via Development wrote:
> I'm trying to compile Qt for Android and 5.12 branch received quite a lot
> configure changes which broke Android builds
> (though I thought that 5.12 branch is for bug fixes only).
>
the series did fix quite some
On Thu, Nov 08, 2018 at 04:26:04PM +0100, Liang Qi wrote:
> I thought qtbase 5.12 got locked since previous email. Looks like not,
> or some people(with privilege) are still eager to hit the stage
> button. I will not try more during tonight.
>
yes, because someone keeps re-adding thiago and
On Thu, Nov 08, 2018 at 08:29:47AM +, Liang Qi wrote:
> I don't know how to use [Grafana] to show the statistic of qtbase 5.12
> integrations in coin. There are only 3 successful integrations
> yesterday: [...]
>
because this situation has been persisting for weeks and we've been
essentially
On Fri, Nov 02, 2018 at 11:59:39AM -0400, Matthew Woehlke wrote:
> On 01/11/2018 08.10, Oswald Buddenhagen wrote:
> > no, instead i told you that your premise of needing a _global_ solver is
> > wrong.
>
> ...but you have failed to explain how dependency resolution will su
On Wed, Oct 31, 2018 at 03:41:49PM -0400, Matthew Woehlke wrote:
> On 31/10/2018 14.26, Oswald Buddenhagen wrote:
> > On Wed, Oct 31, 2018 at 01:09:13PM -0400, Matthew Woehlke wrote:
> >> Again, how then does the consuming tool know which qt.core and which
> >> qt.g
On Wed, Oct 31, 2018 at 01:09:13PM -0400, Matthew Woehlke wrote:
> On 31/10/2018 12.46, Oswald Buddenhagen wrote:
> > On Wed, Oct 31, 2018 at 10:17:04AM -0400, Matthew Woehlke wrote:
> >> On 30/10/2018 17.51, Oswald Buddenhagen wrote:
> >>> after much thinking
On Wed, Oct 31, 2018 at 10:17:04AM -0400, Matthew Woehlke wrote:
> On 30/10/2018 17.51, Oswald Buddenhagen wrote:
> > for starters just some food for thought:
> > QBS-995 should be implementable on top of it.
> > if you want to go full monty, QBS-942 is your target.
>
&
On Wed, Oct 31, 2018 at 11:16:18AM +0100, Robin Burchell wrote:
> On Tue, Oct 30, 2018, at 5:40 PM, Oswald Buddenhagen wrote:
> > on top of that there are long-term savings to be made from increased
> > productivity (which several posters to this thread have confirmed or
> >
On Tue, Oct 30, 2018 at 02:07:16PM -0700, Thiago Macieira wrote:
> On Tuesday, 30 October 2018 13:47:00 PDT Oswald Buddenhagen wrote:
> > On Tue, Oct 30, 2018 at 12:53:48PM -0700, Thiago Macieira wrote:
> > > On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen wrot
On Tue, Oct 30, 2018 at 05:06:44PM -0400, Matthew Woehlke wrote:
> On 30/10/2018 14.25, Oswald Buddenhagen wrote:
> > On Tue, Oct 30, 2018 at 01:46:49PM -0400, Matthew Woehlke wrote:
> >> In order to actually implement the ability to read CMake interface
> >> files
On Tue, Oct 30, 2018 at 12:53:48PM -0700, Thiago Macieira wrote:
> On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen wrote:
> > doesn't authorize you to impose requirements that make it basically
> > impossible to employ qt as a bootstrapping device for a qb
On Tue, Oct 30, 2018 at 12:01:59PM -0700, Thiago Macieira wrote:
> The requirement was not of the tool to be packaged.
>
> It was of one similar-complexity package *using* the buildsystem to be
> packaged for 2 years.
>
err, right.
but quite frankly, i call foul on that one and some other items
On Tue, Oct 30, 2018 at 02:47:43PM -0400, Matthew Woehlke wrote:
> On 30/10/2018 14.30, Edward Welbourne wrote:
> > Painful as [CMake's] syntax is (I've begun reviewing the work for
> > it), it's there, someone else is supporting it, and the expected
> > time to the final demise of qmake does look
On Tue, Oct 30, 2018 at 01:46:49PM -0400, Matthew Woehlke wrote:
> On 30/10/2018 13.17, Oswald Buddenhagen wrote:
> > it's much easier to make qbs generate **and even read** cmake
> > interface files than to re-architect cmake to make it, well, sane.
> (Emphasis added.)
>
&
On Tue, Oct 30, 2018 at 10:41:17AM +0100, Jean-Michaël Celerier wrote:
> I'd like to point you to a mailing list message of Brad King from a
> few months ago about alternative languages for CMake [...]
> So, why not just go and propose the declarative QBS syntax as a
> front-end for CMake?
>
or,
On Tue, Oct 30, 2018 at 01:16:43PM +0200, Bogdan Vatra wrote:
> c.2) back then, none of the existing build system could deliver enough
> information to IDEs to enable prefect code completion (e.g. include
> paths, defines, compiler flags, etc.)
> ...
> c.2) Incomplete! A while ago, I created a
On Tue, Oct 30, 2018 at 09:10:27AM -0700, Thiago Macieira wrote:
> Is it packaged in a Linux distribution? My requirements also included
> continuously packaged for 2 years in at least 3 Linux distributions,
> at the time of the Qt switch to the particular buildsystem.
>
it's been packaged for
On Mon, Oct 29, 2018 at 12:17:04PM +, Lars Knoll wrote:
> while Qbs is pretty cool and interesting technology, it doesn’t really
> help us expand the Qt ecosystem and usage.
>
you actually don't know that. wide adoption outside the qt ecosystem
would create mindshare for the qt project &
On Sun, Oct 28, 2018 at 01:59:07PM -0400, Kyle Edwards wrote:
>However, I'm not sure how to create a new Qt module that's visible
>to the tests without also being installed/visible outside the
>tests.
>
that's an unsolved problem.
qtmultimedia/tests/auto/unit/qmediaserviceprovider also
On Tue, Oct 02, 2018 at 10:37:24AM +0200, André Hartmann wrote:
> I allready have some ideas for QCanBusDevice which requires
> binary-incompatible changes and therefore needs to be done for Qt6 [1].
>
> To be able to already start the work, I'm hereby requesting a wip branch
> that could be
On Fri, Aug 10, 2018 at 03:57:31PM +0200, Shawn Rutledge wrote:
> On 10 Aug 2018, at 15:14, Oswald Buddenhagen wrote:
> > secondly, as your own caveat highlights, you need to encode and
> > maintain policy in the script to make that work.
>
> Starting to use the Fixes: t
On Fri, Aug 10, 2018 at 02:42:59PM +0200, Shawn Rutledge wrote:
> On 10 Aug 2018, at 12:07, Oswald Buddenhagen wrote:
> > so now i think the hook/intergration should just set the fix version to
> > the target branch name. yes, that implies that we should have the
> >
On Fri, Aug 10, 2018 at 08:38:46AM +, Alexander Blasche wrote:
> Thiago Macieira wrote:
> > On Wednesday, 8 August 2018 23:39:16 PDT Alex Blasche wrote:
> > > That is the current approach and it does not work or scale.
> > > Between branching time and release time is a fairly long time. By
>
On Tue, Aug 07, 2018 at 04:06:38PM +0200, Frederik Gladhorn wrote:
> On tirsdag 7. august 2018 14.14.56 CEST Oswald Buddenhagen wrote:
> > https://gerrit-review.googlesource.com/admin/repos/plugins/hooks-jira ?
> > did your investigation reveal that it's unsalvagably bad?
>
1 - 100 of 688 matches
Mail list logo
