On Monday, 14 January 2019 02:02:46 PST Christian Gagneraud wrote:
> My own, cheap/useless opinion is that the Qt company should have
> contacted gitlab or the like...
> Look at what they did with Drupal.
Those options didn't exist when the investment was done.
--
Thiago Macieira - thiago.maciei
On Tue, 8 Jan 2019 at 02:42, Edward Welbourne wrote:
>
> On Mon, 17 Dec 2018 at 21:43, Jean-Michaël Celerier wrote:
> >> But in this day and age where docker works everywhere I don't really
> >> see the point in fighting to make windows behave like a proper unix
> >> system, just write a dockerscr
On Mon, 17 Dec 2018 at 21:43, Jean-Michaël Celerier wrote:
>> But in this day and age where docker works everywhere I don't really
>> see the point in fighting to make windows behave like a proper unix
>> system, just write a dockerscript that does your cross-compile job.
Christian Gagneraud (17 D
On Tuesday, 18 December 2018 14:14:57 PST Sérgio Martins wrote:
> Can't pronounce about the TQC decision, but the qt-project decision is
> easy: We won't choose a build system with unclear future, with vague
> declarations of intent by 1 maintainer.
The question here was only about Qt Creator's pl
On Tue, Dec 18, 2018 at 9:43 PM Richard Weickelt wrote:
>
> On 18.12.2018 21:20, Thiago Macieira wrote:
> > On Tuesday, 18 December 2018 11:44:38 PST Denis Shienkov wrote:
> >> If Qt maintainers says that they will not remove the QtCreator && QBS
> >> integration in future (I'm about QBS project m
On 18.12.2018 21:20, Thiago Macieira wrote:
> On Tuesday, 18 December 2018 11:44:38 PST Denis Shienkov wrote:
>> If Qt maintainers says that they will not remove the QtCreator && QBS
>> integration in future (I'm about QBS project manager plugin), then I
>> will not worry (don't care) about CMake.
On Tue, Dec 18, 2018 at 12:20:37PM -0800, Thiago Macieira wrote:
> On Tuesday, 18 December 2018 11:44:38 PST Denis Shienkov wrote:
> > If Qt maintainers says that they will not remove the QtCreator && QBS
> > integration in future (I'm about QBS project manager plugin), then I
> > will not worry (d
> On Sunday, 16 December 2018 20:12:47 PST Richard Weickelt wrote:
>> ... and if you cross-compile, you definetly don't want to your build system
>> to stick its nose into your system librararies on any platform.
>
> No, you really DO. The issue is what "system" is: it's the sysroot for your
> t
On Tuesday, 18 December 2018 11:44:38 PST Denis Shienkov wrote:
> If Qt maintainers says that they will not remove the QtCreator && QBS
> integration in future (I'm about QBS project manager plugin), then I
> will not worry (don't care) about CMake. I will use QBS in any case.
So long as someone i
> preferably one that doesn't involve Qt specific stuff
A main point is that we discuss about using the CMake as an 'advanced'
buld system in context of Qt.
> Please show a concrete example
I already provided that example - it is cross-compilation. You can try
to cross-compile a simple appli
On Tuesday, 18 December 2018 10:38:09 PST Matthew Woehlke wrote:
> > I work in the Anaconda Distribution as a software packager and spend
> > a significant amount of my working day battling cmake. As I say it's
> > "ok" for developers but not for packagers.
>
> AFAIK, that experience is inconsiste
On Dec 18, 2018 12:33 PM, "Matthew Woehlke"
wrote:
On 15/12/2018 15.49, Ray Donnelly wrote:
> Do you know for example that cmake will find dlls in C:\Windows\System32,
Uh... yeah? I think most people *expect* that...
Would you also rather CMake didn't look in /usr/lib[64] on Linux
systems? *Why
On 16/12/2018 12.00, Denis Shienkov wrote:
> As we all can see, the CMake loses even QBS. We need to spent a tens of
> hours/days to find out the solution, using CMake's , but with QBS same
> issue solves for 30 mins or work immediatelly. Its very funny.
Really? Because *I* don't see that.
This
On 16/12/2018 08.21, Ray Donnelly wrote:
> In particular ide generators cannot express complex build
> dependencies very well and any use of scripts will tend not to work unless
> you hardcore them for each one.
Scripts can be problematic if they need to run stuff that is part of the
build, althou
On 15/12/2018 15.49, Ray Donnelly wrote:
> Do you know for example that cmake will find dlls in C:\Windows\System32,
Uh... yeah? I think most people *expect* that...
Would you also rather CMake didn't look in /usr/lib[64] on Linux
systems? *Why*?
> find_package is still inscrutable, and it's for
Christian Gagneraud wrote:
> Fairly interesting indeed, and very surprising too, this WIN32/Android
> stuff was fixed last week, i didn't invent it.
> Maybe, we ran into bad luck.
The bug you ran to only hits you when ALL 3 of the following conditions are
satisfied:
1. Windows build host,
2. non-
On Mon, 17 Dec 2018 at 21:43, Jean-Michaël Celerier
wrote:
> > CMake doesn't support (very well) cross-compilation for android on
> > Windows for example,
>
> fairly interesting considering that Android Studio uses CMake:
> https://developer.android.com/studio/projects/add-native-code
Fairly int
> Does pkg-config and cmake works on Qnx and Windows? Can you cross
> compile for iOS, tvOS, ... using CMake?
> Has it been ever tried once?
Seriously, it's a google search away: https://github.com/leetal/ios-cmake
> CMake doesn't support (very well) cross-compilation for android on
> Windows for
On Mon, 17 Dec 2018 at 17:53, Ray Donnelly wrote:
> On Sun, Dec 16, 2018, 10:36 PM Richard Weickelt > The discussion about build systems reminds me a bit of a religious war. I
>> made my peace with CMake and use it only when being paid for. It allows me
>> to use the browser more often and to find
On Mon, 17 Dec 2018 at 18:38, Thiago Macieira wrote:
>
> On Sunday, 16 December 2018 20:12:47 PST Richard Weickelt wrote:
> > ... and if you cross-compile, you definetly don't want to your build system
> > to stick its nose into your system librararies on any platform.
>
> No, you really DO. The i
On Sunday, 16 December 2018 20:12:47 PST Richard Weickelt wrote:
> ... and if you cross-compile, you definetly don't want to your build system
> to stick its nose into your system librararies on any platform.
No, you really DO. The issue is what "system" is: it's the sysroot for your
target platf
On Sun, Dec 16, 2018, 10:36 PM Richard Weickelt
> > Here in Fedora, we actually *want* CMake to find system libraries. The
> > situation on Windows is of course different, and third-party packages
> for
> > GNU/Linux may or may not want to use the system libraries, but our
> > distribution package
> Here in Fedora, we actually *want* CMake to find system libraries. The
> situation on Windows is of course different, and third-party packages for
> GNU/Linux may or may not want to use the system libraries, but our
> distribution packages definitely want to use them.
... and if you cross-co
On Sunday, 16 December 2018 12:00:29 PST Ray Donnelly wrote:
> it seems to have taken
> over) is that I prefer it to bazel in most respects.
Bazel and gyp are in the list of systems packagers positively hate in our
case.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect -
Ray Donnelly wrote (NOTE: I reordered the quotes so that my replies can be
read in order):
> I work in the Anaconda Distribution as a software packager and spend a
> significant amount of my working day battling cmake. As I say it's "ok"
> for developers but not for packagers.
I'm a packager for
On 2018 M12 16, Sun 07:21:35 CET Ray Donnelly wrote:
> I'll not going to do this for you, sorry. I also pointed out the lack of
> isolation from system libraries by default as a major problem.
just to make sure we are talking about the same: basically you are saying that
the Visual Studio generat
The
On Sun, Dec 16, 2018, 1:17 PM Thiago Macieira On Sunday, 16 December 2018 05:21:35 PST Ray Donnelly wrote:
> > As I say it's "ok" for developers but not for
> > packagers.
>
> Which one is ok for packagers?
>
> In Clear Linux, we also have people who dislike CMake. They recommend only
> Auto
On 12/16/2018 08:05 PM, Thiago Macieira wrote:
On Sunday, 16 December 2018 05:21:35 PST Ray Donnelly wrote:
As I say it's "ok" for developers but not for
packagers.
Which one is ok for packagers?
From packaging standpoint, autotools are clearly the best. But I would
say cmake is ok for 2n
On Sunday, 16 December 2018 09:00:29 PST Denis Shienkov wrote:
> As we all can see, the CMake loses even QBS. We need to spent a tens of
> hours/days to find out the solution, using CMake's , but with QBS same
> issue solves for 30 mins or work immediatelly. Its very funny.
Then by all means cont
On Sunday, 16 December 2018 05:21:35 PST Ray Donnelly wrote:
> As I say it's "ok" for developers but not for
> packagers.
Which one is ok for packagers?
In Clear Linux, we also have people who dislike CMake. They recommend only
Autoconf and Meson.
--
Thiago Macieira - thiago.macieira (AT) int
> I work in the Anaconda Distribution as a software packager and spend
a significant amount of my working day battling cmake.
As we all can see, the CMake loses even QBS. We need to spent a tens of
hours/days to find out the solution, using CMake's , but with QBS same
issue solves for 30 mins
I'll not going to do this for you, sorry. I also pointed out the lack of
isolation from system libraries by default as a major problem.
Take any complex project and try it. Basically very few will work on all
generators. In particular ide generators cannot express complex build
dependencies very w
Hi,
On 2018 M12 15, Sat 14:49:16 CET Ray Donnelly wrote:
> On Sat, Dec 15, 2018, 6:35 AM Alexander Neundorf > On 2018 M10 30, Tue 18:33:03 CET NIkolai Marchenko wrote:
> > > > Thus this investment would be at the expense of other things we’d like
> >
> > to
> >
> > > do, like improving our IDE,
On Sat, Dec 15, 2018, 6:35 AM Alexander Neundorf On 2018 M10 30, Tue 18:33:03 CET NIkolai Marchenko wrote:
> > > Thus this investment would be at the expense of other things we’d like
> to
> >
> > do, like improving our IDE, working on rearchitecting and cleaning up our
> > core frameworks for Qt
On 2018 M10 30, Tue 18:33:03 CET NIkolai Marchenko wrote:
> > Thus this investment would be at the expense of other things we’d like to
>
> do, like improving our IDE, working on rearchitecting and cleaning up our
> core frameworks for Qt 6 or the design tooling we are currently investing
> into.
> 29 okt. 2018 kl. 08:17 skrev Lars Knoll :
>
> As you will probably remember, there have been lively discussions around what
> kind of build tool to use for Qt 6 both during Qt Contributor Summits as well
> as on this mailing list.
>
> There has been a strong consent that we should move away
On 02/11/2018 13.39, Oswald Buddenhagen wrote:
> i honestly don't understand what your problem is. the only difference
> between the approaches is that you centralize the meta data, while i
> distribute it. TTA works exactly the same way.
My approach forces packages to be transactional. Either you
On 10/30/18 12:16 PM, Bogdan Vatra via Development wrote:
>>> d) While c.1 and c.2 can be fixed with some effort, here we have bigger
>>> problems:
>>>
>>>- Instread to port QBS to QML JS in the first second when QtScript was
>>> deprecated, they fork it! I know that back then QML JS neede
Hi,
În ziua de luni, 12 noiembrie 2018, la 15:06:00 EET, Joerg Bornemann a scris:
> On 10/30/18 12:16 PM, Bogdan Vatra via Development wrote:
>
> Late to the game, but I feel the urge to comment on some things.
>
>
> > c.2) Incomplete! A while ago, I created a QBS plugin for KDevelop[1] and
> >
On 10/30/18 12:16 PM, Bogdan Vatra via Development wrote:
Late to the game, but I feel the urge to comment on some things.
> c.2) Incomplete! A while ago, I created a QBS plugin for KDevelop[1] and I
> found some problems, see how QBS developers treat them here: https://
> bugreports.qt.io/browse
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 succeed
> in a scenario suc
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 succeed
in a scenario such as I have outlined.
Actually, I realize now there is a possible answer: it
> On 30 Oct 2018, at 22:57, Christian Gagneraud wrote:
>
> Hi Lars,
>
> On Tue, 30 Oct 2018 at 23:42, Lars Knoll wrote:
>>> On 30 Oct 2018, at 05:00, Christian Gagneraud wrote:
>>> On Tue, 30 Oct 2018 at 01:17, Lars Knoll wrote:
>>> Then why spend energy/money to fix something that is broken
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.gui are compatible with each other
nt on
behalf of Simon Hausmann
Sent: Thursday, November 1, 2018 12:19:11 PM
To: André Pönitz
Cc: development mailing list; q...@qt-project.org
Subject: Re: [Development] Build system for Qt 6
I agree, this is often the case.
I just wanted to emphasize that I think it’s too early to conclude tha
I agree, this is often the case.
I just wanted to emphasize that I think it’s too early to conclude that llvm is
going to switch to gn based on that email. It’s convenient to quote what adds
fuel to the fire of this discussion. Hence my attempt to add water by quoting
what I thought it still re
Especially considering that the person proposing the change is working
at google which is where GN comes from. There's some conflict of
interest here.
On 01/11/2018 12:13, André Pönitz wrote:
On Thu, Nov 01, 2018 at 08:34:34AM +, Simon Hausmann wrote:
>From the same email perhaps it's als
On Thu, Nov 01, 2018 at 08:34:34AM +, Simon Hausmann wrote:
>
> >From the same email perhaps it's also worth quoting the first paragraph:
> "
>
> first things first: If you're happy with cmake, you can stop reading now.
> Nobody is proposing that LLVM moves off cmake, and nobody is proposing
Hi,
Yes, "hard to work with" :).
Cheers,
BogDan.
În ziua de joi, 1 noiembrie 2018, la 11:24:29 EET, Vlad Stelmahovsky a scris:
> you mean "hard to work with"?
>
> On 11/1/18 9:34 AM, Bogdan Vatra via Development wrote:
> > Hi,
> >
> >GN is the closest build system to QBS, the only problem
you mean "hard to work with"?
On 11/1/18 9:34 AM, Bogdan Vatra via Development wrote:
Hi,
GN is the closest build system to QBS, the only problem it has it's
controled by Google and these guys are sometime had to work with.
Cheers,
BogDan.
În ziua de joi, 1 noiembrie 2018, la 10:30:01 EET,
ke more work.
"
Simon
From: Development on
behalf of Nikolai Kosjar
Sent: Thursday, November 1, 2018 9:30:01 AM
To: Lars Knoll; Qt development mailing list
Subject: Re: [Development] Build system for Qt 6
On 10/29/18 1:17 PM, Lars Knoll wrote:
> Given that we
Hi,
GN is the closest build system to QBS, the only problem it has it's
controled by Google and these guys are sometime had to work with.
Cheers,
BogDan.
În ziua de joi, 1 noiembrie 2018, la 10:30:01 EET, Nikolai Kosjar a scris:
> On 10/29/18 1:17 PM, Lars Knoll wrote:
> > Given that we are c
On 10/29/18 1:17 PM, Lars Knoll wrote:
> Given that we are confident we can build Qt 6 with cmake, I believe that it
> makes most sense to follow down that route.
Just some observation:
LLVM/Clang is a bigger project using CMake for some longer time and
coincidentally, just now, there is a dis
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.gui are compatible with each other? How does it handle the case of
>> finding a qt.core with no matching qt
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 about the matter, i concluded that the
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 about the matter, i concluded that the interface
>>> files should correspond to "atomic linkable entities", whi
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.
>
> What are those? Can you pro
>Date: Wed, 31 Oct 2018 08:28:45 -0700
>From: Thiago Macieira
>To:
>Subject: Re: [Development] Build system for Qt 6
>Message-ID: <7867869.XuAOyZs5DA@tjmaciei-mobl1>
>Content-Type: text/plain; charset="iso-8859-1"
>
>>On Tuesday, 30 October 2018 22:59:
On Tuesday, 30 October 2018 22:59:57 PDT André Pönitz wrote:
> Where would a QBS-promoting webpage be located?
>
> qt-project.org ?
Sure, why not?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
__
On Wednesday, 31 October 2018 03:02:04 PDT Bernhard Lindner wrote:
> Maybe I worked for the wrong companies all the time. But whenever we wanted
> to have proof that some tool or library actually meets our requirements, it
> never was sufficient to *ask* for proof. We needed to test it by *ourselfs
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.
What are those? Can you provide links?
> one thing i noticed is that you multiplex build variants and o
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
> > implied). that alone wo
On 31. Oct 2018, at 06:38, Bogdan Vatra via Development
mailto:development@qt-project.org>> wrote:
Hi,
În ziua de marți, 30 octombrie 2018, la 19:11:20 EET, Oswald Buddenhagen a
scris:
On Tue, Oct 30, 2018 at 01:16:43PM +0200, Bogdan Vatra wrote:
c.2) back then, none of the existing build syste
On Wed, 31 Oct 2018 at 22:47, Christian Kandeler
wrote:
>
> On Wed, 31 Oct 2018 10:44:43 +1300
> Christian Gagneraud wrote:
>
> > On Wed, 31 Oct 2018 at 10:27, Thiago Macieira
> > wrote:
> > > On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote:
> > > The only thing I'm criticising
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
> implied). that alone won't offset the cost vs. using cmake (it would vs.
> developing and using
Hi!
> No. However, I am asking for proof.
Maybe I worked for the wrong companies all the time. But whenever we wanted to
have proof
that some tool or library actually meets our requirements, it never was
sufficient to
*ask* for proof. We needed to test it by *ourselfs* in a feasibility project.
On Wed, 31 Oct 2018 10:44:43 +1300
Christian Gagneraud wrote:
> On Wed, 31 Oct 2018 at 10:27, Thiago Macieira
> wrote:
> > On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote:
> > The only thing I'm criticising is that its proper chance involves Qt being
> > the
> > guinea pig. Fi
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 wrote:
> > > > doesn't authori
On Wed, 31 Oct 2018 at 11:08, Thiago Macieira wrote:
> On Tuesday, 30 October 2018 14:44:43 PDT Christian Gagneraud wrote:
> > On Wed, 31 Oct 2018 at 10:27, Thiago Macieira
> wrote:
> > > On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote:
> > > The only thing I'm criticising is tha
See: “deprecated”
From: Development on
behalf of Uwe Rathmann
Sent: Wednesday, October 31, 2018 2:35:50 AM
To: development@qt-project.org
Subject: Re: [Development] Build system for Qt 6
On Tue, 30 Oct 2018 19:24:26 +, Adam Treat wrote:
> Lars gav
On Tue, 30 Oct 2018 19:24:26 +, Adam Treat wrote:
> Lars gave a keynote saying pretty much the same. Simply is not true that
> we are planning major source compatible breakage for Qt6 so let's stop
> saying that.
When will the already deprecated QQuickControls 1 module going to be
finally re
Hi,
În ziua de marți, 30 octombrie 2018, la 19:11:20 EET, Oswald Buddenhagen a
scris:
> 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
On Tue, Oct 30, 2018 at 02:44:03PM -0700, Thiago Macieira wrote:
> On Tuesday, 30 October 2018 14:33:41 PDT NIkolai Marchenko wrote:
> > Tbh, we wouldn't if this post hasn't almost stated that you are pulling the
> > plug.
> > As I saw it: qbs folks have finally started doing the correct thiing (th
On Tuesday, 30 October 2018 14:57:01 PDT Christian Gagneraud wrote:
> > Looking at the fact, that we can’t earn money on a build system and that
> > it would require quite a lot of funding to make it more than a niche
> > product it doesn’t make sense to pursue it further. Instead we would
> > rath
On Tuesday, 30 October 2018 14:44:43 PDT Christian Gagneraud wrote:
> On Wed, 31 Oct 2018 at 10:27, Thiago Macieira
wrote:
> > On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote:
> > The only thing I'm criticising is that its proper chance involves Qt being
> > the guinea pig. Find
Hi Lars,
On Tue, 30 Oct 2018 at 23:42, Lars Knoll wrote:
> > On 30 Oct 2018, at 05:00, Christian Gagneraud wrote:
> > On Tue, 30 Oct 2018 at 01:17, Lars Knoll wrote:
> > Then why spend energy/money to fix something that is broken by design?
> > (Again, that is a personal opinion, if needed to s
Even the initial support for Qt6 will already make community based efforts
more likely since they will at least have something to work with.
But if QBS support in QtCreator is dropped as Qt6 releases there is little
to no chance of anyone picking it up as he task might just be too large.
_
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 (without corner cases), you basic
Tbh, as I see it: qbs is mostly usable now. The only thing it needs to stay
afloat from now on and have a chance is promise of support for it + qt6 in
qt creator.
Is that really that hard to do?
On Wed, Oct 31, 2018 at 12:37 AM Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com> wrote:
> Yes
On Wed, 31 Oct 2018 at 10:27, Thiago Macieira wrote:
> On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote:
> The only thing I'm criticising is that its proper chance involves Qt being the
> guinea pig. Find someone else instead and grow your community. Get track
> record for building
On Tuesday, 30 October 2018 14:33:41 PDT NIkolai Marchenko wrote:
> Tbh, we wouldn't if this post hasn't almost stated that you are pulling the
> plug.
> As I saw it: qbs folks have finally started doing the correct thiing (that
> is - tutorials) and what you are speaking of had a chance to happen.
Yes, it's a big requirement for a lot of people using OFX that they be
able to use also Xcode and / or Visual Studio. But QBS was at some point
(not sure if still the case) the main one.
On 30/10/2018 22:25, Иван Комиссаров wrote:
Huh? Looks like they are supporting every build system alive
ht
> Don't ask Qt to switch to it until you've done that work.
Tbh, we wouldn't if this post hasn't almost stated that you are pulling the
plug.
As I saw it: qbs folks have finally started doing the correct thiing (that
is - tutorials) and what you are speaking of had a chance to happen.
But as of ri
On Tuesday, 30 October 2018 14:15:46 PDT NIkolai Marchenko wrote:
> Maybe, but then, you've spent quite some time developing the system ,what's
> stopping you from reaching out to suitable projects that involve packaging
> to help them set up their project with QBS?
> Instead of stating your desire
On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote:
> > and has enough of a track record of a community to ask for help.
>
> You quite literally have the system's developer in house.
> Why do you even need to rely on the community so much?
> I'd understand if qbs was an external tool
Huh? Looks like they are supporting every build system alive
https://github.com/openframeworks/openFrameworks/tree/patch-release/libs/openFrameworksCompiled/project
> 30 окт. 2018 г., в 22:14, Jean-Michaël Celerier
> написал(а):
>
> OpenFrameworks, a fairly used creative coding framework has b
> I'm not disputing it has quality. But it lacks a specific community I
called
for: packagers.
Maybe, but then, you've spent quite some time developing the system ,what's
stopping you from reaching out to suitable projects that involve packaging
to help them set up their project with QBS?
Instead
OpenFrameworks, a fairly used creative coding framework has been using QBS
for a few years. My experience with it in that context has been quite
negative - a year ago it would break on every new QBS release, so you had
to use an exact QBS version if you wanted to use OFX (exhibit A:
https://forum.o
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 wrote:
> > > doesn't authorize you to impose requirements that make it basically
> > > impossible to
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 (without corner cases), you basically have to *be* CMake.
>> If you assume that you will only have to deal
> and has enough of a track record of a community to ask for help.
You quite literally have the system's developer in house.
Why do you even need to rely on the community so much?
I'd understand if qbs was an external tool, but that's not the case.
On Tue, Oct 30, 2018 at 11:49 PM Konstantin She
On Tue, Oct 30, 2018 at 9:09 PM Thiago Macieira
wrote:
> On Tuesday, 30 October 2018 10:26:15 PDT Konstantin Shegunov wrote:
> > From my point of view qbs is doomed as long as qmake's alive. Either kill
> > qmake and force the developers using Qt (or developing Qt) to use qbs
>
> That's not going
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 qbs
> > ecosystem.
>
> The whole
On Tuesday, 30 October 2018 12:21:25 PDT NIkolai Marchenko wrote:
> > No, we will break source compatibility in a minor way.
>
> I am not aware of what was the end result of QList discussion, but didn't
> you want to deprecate/majorly change that at some point?
> That alone would be rather huge.
On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen wrote:
> 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.
>
> But the fact that in 4 years there is just one package in Debian's
archive using qbs says a lot.
Unfortunately all it says is that QBS developers _really_ didn't care to
advertise/document their system.
it's no wonder there are no projects when the only thing you have to work
off of is a bunch
El martes, 30 de octubre de 2018 15:26:14 -03 Иван Комиссаров escribió:
> Wow, hold on for a minute.
> I’ve been using a qbs package as a standalone leaf package (sudo aptitude
> install qbs) to build my projects. Also, self-built QBS package was
> commercially used to create several Debian package
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
Lars gave a keynote saying pretty much the same. Simply is not true that
we are planning major source compatible breakage for Qt6 so let's stop
saying that.
On 10/30/2018 03:19 PM, Thiago Macieira wrote:
> On Tuesday, 30 October 2018 12:11:38 PDT NIkolai Marchenko wrote:
>> > That's not going
> No, we will break source compatibility in a minor way.
I am not aware of what was the end result of QList discussion, but didn't
you want to deprecate/majorly change that at some point?
That alone would be rather huge.
On Tue, Oct 30, 2018 at 10:19 PM Thiago Macieira
wrote:
> On Tuesday, 30
1 - 100 of 176 matches
Mail list logo
