On Monday, 27 August 2018 16:50:43 PDT Lisandro Damián Nicanor Pérez Meyer
wrote:
> That's right, it will allow less disk usage for sure. But I don't know up to
> which point is a "nice to have" feature or something that would really
> decrease disk usage.
Strictly speaking, it would be no worse.
El domingo, 26 de agosto de 2018 20:12:51 -03 Kevin Kofler escribió:
> Thiago Macieira wrote:
> > Also note that QML files are usually cross-platform too and could be
> > shared. Any non-cross-platform QML file should be selected by the source
> > via QFileSelector. Plugins, however, are arch-depen
Thiago Macieira wrote:
> Also note that QML files are usually cross-platform too and could be
> shared. Any non-cross-platform QML file should be selected by the source
> via QFileSelector. Plugins, however, are arch-dependent and should live in
> an arch-dependent dir. That would mean splitting th
On Tuesday, July 31, 2018 8:15:50 PM CEST Ville Voutilainen wrote:
> On 31 July 2018 at 20:49, Thiago Macieira wrote:
> > I know CMake meets these requirements, but it has other problems and the
> > fact that it currently does not build Qt. On that front, qbs is ahead.
> > But qbs has a shorter tr
On 2018 M07 21, Sat 18:24:23 CEST Giuseppe D'Angelo via Development wrote:
> Il 21/07/2018 17:42, Jean-Michaël Celerier ha scritto:
> > Besides... why would it matter that they are implemented in C++ instead
> > of cmake-lang ? If anything, CMake's automoc is in my experience much
> > faster to pro
On Thursday, 2 August 2018 23:46:07 PDT Jason Newton wrote:
> From OpenSUSE build service, here is the build time for the full
> OpenJDK 8 build
> https://build.opensuse.org/public/build/Java:Factory/openSUSE_Leap_15.0/x86_
> 64/java-1_8_0-openjdk/_log - 1976 seconds with what appears to be a singl
On Thursday, 2 August 2018 23:42:08 PDT BogDan Vatra via Development wrote:
> Sorry it's kinda off-topic. What I wanted to say is for Qt 6 to have a new
> SDK folders layout. Now each Qt target goes into a separate folder, but the
> bin, include (except a few files), doc, mkspecs, etc. folders are
On Thu, Aug 2, 2018 at 11:21 PM Dominik Holland
wrote:
>
> Am 01.08.18 um 16:40 schrieb Ville Voutilainen:
>
> > On 1 August 2018 at 11:24, Jason Newton wrote:
> >>> And... seriously, *Java*?! Talk about bloat-ware... As dependencies for
> >>> *a build tool* go, that's pretty insane. Especially i
În ziua de joi, 2 august 2018, la 18:06:02 EEST, Thiago Macieira a scris:
> On Wednesday, 1 August 2018 23:13:13 PDT BogDan Vatra via Development wrote:
> > > Now that is nice, as we know that the moc, uic, rcc outputs are
> > > platform-
> > > independent. That should help reduce the build times o
Am 01.08.18 um 16:40 schrieb Ville Voutilainen:
> On 1 August 2018 at 11:24, Jason Newton wrote:
>>> And... seriously, *Java*?! Talk about bloat-ware... As dependencies for
>>> *a build tool* go, that's pretty insane. Especially if you're not
>>> planning to use it to build Java code.
>> As I sai
On Thursday, 2 August 2018 10:36:11 PDT Konstantin Tokarev wrote:
> Do you have any prominent examples?
No, sorry. We don't need to cross-compile at the company I work for :-)
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
__
El jueves, 2 de agosto de 2018 14:36:11 -03 Konstantin Tokarev escribió:
> 02.08.2018, 19:50, "Thiago Macieira" :
> > On Thursday, 2 August 2018 07:16:18 PDT Konstantin Tokarev wrote:
> >> Unfortunately, Debian does not use cross-compilation for building
> >> packages
> >
> > Which is unfortunate
On Thu, Aug 2, 2018 at 9:34 AM Matthew Woehlke wrote:
>
> On 2018-08-02 09:03, Oswald Buddenhagen wrote:
> > On Wed, Aug 01, 2018 at 10:33:43AM -0400, Matthew Woehlke wrote:
> >> On 2018-08-01 04:24, Jason Newton wrote:
> >>> On Mon, Jul 30, 2018 at 1:30 PM Matthew Woehlke wrote:
> Persistent
02.08.2018, 19:50, "Thiago Macieira" :
> On Thursday, 2 August 2018 07:16:18 PDT Konstantin Tokarev wrote:
>> Unfortunately, Debian does not use cross-compilation for building packages
>
> Which is unfortunately the case for most (if not all) Linux distributions as a
> significant number of fram
El jueves, 2 de agosto de 2018 10:57:42 -03 Christian Kandeler escribió:
[snip]
> > But would be problematic when building for other archs not that powerful
> > as
> > "the normal ones".
>
> You mean *on* other archs? Because the (cross-)compiler does not care how
> powerful the target architectu
On Thursday, 2 August 2018 07:16:18 PDT Konstantin Tokarev wrote:
> Unfortunately, Debian does not use cross-compilation for building packages
Which is unfortunately the case for most (if not all) Linux distributions as a
significant number of frameworks and applications don't cross compile at al
On 2018-08-02 09:03, Oswald Buddenhagen wrote:
> On Wed, Aug 01, 2018 at 10:33:43AM -0400, Matthew Woehlke wrote:
>> On 2018-08-01 04:24, Jason Newton wrote:
>>> On Mon, Jul 30, 2018 at 1:30 PM Matthew Woehlke wrote:
Persistent build server? Java? No, thanks.
>>>
>>> This is an option, you can
On Wednesday, 1 August 2018 23:40:40 PDT Lars Knoll wrote:
> > Right, moc files are not cross-platform but I think rcc & uic files are.
>
> They are still build artefacts, and trying to add logic to figure out which
> of those can be shared between different targets and which can’t sounds
> like a
On Wednesday, 1 August 2018 23:18:51 PDT Simon Hausmann wrote:
> Given that the output of the moc changes depending on what platform and
> compiler dependent pre-processor macros are supplied, I would say that the
> output is not cross-platform.
True, even in debug-and-relaese they could change, a
On Wednesday, 1 August 2018 23:13:13 PDT BogDan Vatra via Development wrote:
> > Now that is nice, as we know that the moc, uic, rcc outputs are platform-
> > independent. That should help reduce the build times on Windows for
> > debug-and- release builds, as running moc is a significant portion o
02.08.2018, 16:58, "Christian Kandeler" :
> On Thu, 2 Aug 2018 10:23:12 -0300
> Lisandro Damián Nicanor Pérez Meyer wrote:
>
>> El jueves, 2 de agosto de 2018 10:03:04 -03 Oswald Buddenhagen escribió:
>> [snip]
>> > > > As for java in the loop - this is a a build system, how much does it
>>
On Thu, 2 Aug 2018 10:23:12 -0300
Lisandro Damián Nicanor Pérez Meyer wrote:
> El jueves, 2 de agosto de 2018 10:03:04 -03 Oswald Buddenhagen escribió:
> [snip]
> > > > As for java in the loop - this is a a build system, how much does it
> > > > matter with what it is written in if the implement
El jueves, 2 de agosto de 2018 10:23:12 -03 Lisandro Damián Nicanor Pérez
Meyer escribió:
> El jueves, 2 de agosto de 2018 10:03:04 -03 Oswald Buddenhagen escribió:
> [snip]
>
> > > > As for java in the loop - this is a a build system, how much does it
> > > > matter with what it is written in if
El jueves, 2 de agosto de 2018 10:03:04 -03 Oswald Buddenhagen escribió:
[snip]
> > > As for java in the loop - this is a a build system, how much does it
> > > matter with what it is written in if the implementation is good?
> >
> > ...because Java is an *enormous* added dependency
>
> the actu
On Wed, Aug 01, 2018 at 10:33:43AM -0400, Matthew Woehlke wrote:
> On 2018-08-01 04:24, Jason Newton wrote:
> > On Mon, Jul 30, 2018 at 1:30 PM Matthew Woehlke wrote:
> >> On 2018-07-21 19:52, Jason Newton wrote:
> >>> I wanted to mention that this is on my mind alot for a few years days
> >>> as a
On Wed, Aug 01, 2018 at 09:01:40AM +, Edward Welbourne wrote:
> Jason Newton (1 August 2018 10:24)
> > One of the things I like about the way bazel keeps this is I can jump
> > back and forth between an optimized build and a full debug build (for
> > example) - they don't erase eachother
>
> T
On 08/02/2018 10:05 AM, BogDan Vatra via Development wrote:
Well, if we want to have first class Qt on Android support, this feature
is a
must. Now, if we can use it also for other platforms that's a
bonus.
Which feature exactly? Creating binaries for multiple targets in on compile
run? Or
În ziua de joi, 2 august 2018, la 11:02:30 EEST, Lars Knoll a scris:
> > On 2 Aug 2018, at 09:52, BogDan Vatra wrote:
> >
> > În ziua de joi, 2 august 2018, la 09:49:48 EEST, Lars Knoll a scris:
> >
> >>> On 2 Aug 2018, at 08:13, BogDan Vatra via Development
> >>> wrote:
> >
> > […]
> >
> >>>
> On 2 Aug 2018, at 09:52, BogDan Vatra wrote:
>
> În ziua de joi, 2 august 2018, la 09:49:48 EEST, Lars Knoll a scris:
>>> On 2 Aug 2018, at 08:13, BogDan Vatra via Development
>>> wrote:
> […]
>>>
>>> It will be nice if this feature is mandatory for Qt 6, so let's add it to
>>>
>>>
>>> you
În ziua de joi, 2 august 2018, la 09:49:48 EEST, Lars Knoll a scris:
> > On 2 Aug 2018, at 08:13, BogDan Vatra via Development
> > wrote:
[…]
> >
> > It will be nice if this feature is mandatory for Qt 6, so let's add it to
> >
> >
> > your requirements list.
>
>
>
> Let’s be careful not
> On 2 Aug 2018, at 08:13, BogDan Vatra via Development
> wrote:
> […]
> It will be nice if this feature is mandatory for Qt 6, so let's add it to
> your requirements list.
Let’s be careful not to add too many requirements upfront or we’ll never get
anywhere.
For me the hard requirements
> On 2 Aug 2018, at 08:38, BogDan Vatra via Development
> wrote:
>
> Hi
> În ziua de joi, 2 august 2018, la 09:33:10 EEST, Joerg Bornemann a scris:
>> On 08/02/2018 08:18 AM, Simon Hausmann wrote:
>>> Given that the output of the moc changes depending on what platform and
>>> compiler dependent
Hi
În ziua de joi, 2 august 2018, la 09:33:10 EEST, Joerg Bornemann a scris:
> On 08/02/2018 08:18 AM, Simon Hausmann wrote:
> > Given that the output of the moc changes depending on what platform and
> > compiler dependent pre-processor macros are supplied, I would say that
> > the output is not c
On 08/02/2018 08:18 AM, Simon Hausmann wrote:
Given that the output of the moc changes depending on what platform and
compiler dependent pre-processor macros are supplied, I would say that the
output is not cross-platform.
...which is why qbs does *not* have such a feature.
moc_XXX.cpp and X
On 2 Aug 2018, at 00:27, Thiago Macieira
mailto:thiago.macie...@intel.com>> wrote:
On Wednesday, 1 August 2018 13:14:32 PDT Sérgio Martins wrote:
On Sat, Jul 21, 2018 at 3:35 AM, Thiago Macieira
mailto:thiago.macie...@intel.com>> wrote:
Hello
Having spent far too much time trying to figure out
Hi,
Given that the output of the moc changes depending on what platform and
compiler dependent pre-processor macros are supplied, I would say that the
output is not cross-platform.
Simon
>> On 2. Aug 2018, at 00:31, Thiago Macieira wrote:
>>
>> On Wednesday, 1 August 2018 12:46:04 PDT BogDan
Hi,
În ziua de joi, 2 august 2018, la 01:31:10 EEST, Thiago Macieira a scris:
> On Wednesday, 1 August 2018 12:46:04 PDT BogDan Vatra via Development wrote:
> > Hi,
> >
> > qmake can't compile them all *at once* e.g. $ qmake && make will compile
> > only one target at the time not all.
> >
> > AF
Bazel's caching mechanism would also optimize away regeneration of
generated outputs (via genrules) across the different toolchains,
provided the tools/scripts and important environmental variables/files
do not change (which would hash to different keys). Further you could
run a disk local cache o
On Wednesday, 1 August 2018 12:46:04 PDT BogDan Vatra via Development wrote:
> Hi,
>
> qmake can't compile them all *at once* e.g. $ qmake && make will compile
> only one target at the time not all.
>
> AFAIK QBS and iirc gn too, are the only few that have this cool feature.
Now that is nice, as
On Wednesday, 1 August 2018 13:14:32 PDT Sérgio Martins wrote:
> On Sat, Jul 21, 2018 at 3:35 AM, Thiago Macieira
>
> wrote:
> > Hello
> >
> > Having spent far too much time trying to figure out why crappy
> > buildsystems
> > cause failures in distros (like TensorFlow or libvpx - see
> > https:
On Wed, Aug 1, 2018 at 8:46 PM, BogDan Vatra via Development
wrote:
> Hi,
>
> qmake can't compile them all *at once* e.g. $ qmake && make will compile
> only one target at the time not all.
>
> AFAIK QBS and iirc gn too, are the only few that have this cool feature.
And probably do a single moc a
On Sat, Jul 21, 2018 at 3:35 AM, Thiago Macieira
wrote:
> Hello
>
> Having spent far too much time trying to figure out why crappy buildsystems
> cause failures in distros (like TensorFlow or libvpx - see
> https://plus.google.com/+ThiagoMacieira/posts/DqTKdRGfuwR ), I'd like to make
> sure this d
Hi,
qmake can't compile them all *at once* e.g. $ qmake && make will compile only
one target at the time not all.
AFAIK QBS and iirc gn too, are the only few that have this cool feature.
Cheers,
BogDan.
On August 1, 2018 10:27:03 PM GMT+03:00, Thiago Macieira
wrote:
>On Wednesday, 1 August 2
On Wednesday, 1 August 2018 11:58:02 PDT BogDan Vatra via Development wrote:
> Hi,
>
> Did you knew that qbs can build all but windows targets at once from your
> Linux machine?
That's not news. qmake can do that, provided you have the toolchains. You
could compile for Mac and MSVC too, if yo
Hi,
Did you knew that qbs can build all but windows targets at once from your
Linux machine? Using mingw you can cross compile Qt for windows, but you
probably want to run tests and to check if the code compiles with msvc.
This feature might not seem pretty useful for linux, but is very usef
On Wednesday, 1 August 2018 02:01:40 PDT Edward Welbourne wrote:
> This is easy to do in any build system that supports out-of-source
> (a.k.a. "shadow") builds - notably including the existing qmake-based
> builds for Qt. I never want to do an in-source build of anything.
And not just that. Buil
On 1 August 2018 at 11:24, Jason Newton wrote:
>> And... seriously, *Java*?! Talk about bloat-ware... As dependencies for
>> *a build tool* go, that's pretty insane. Especially if you're not
>> planning to use it to build Java code.
>
> As I said, ~300-400 megabytes for a JRE (~90MiB DL), in parti
On 2018-08-01 04:24, Jason Newton wrote:
> On Mon, Jul 30, 2018 at 1:30 PM Matthew Woehlke wrote:
>> On 2018-07-21 19:52, Jason Newton wrote:
>>> I wanted to mention that this is on my mind alot for a few years days
>>> as a user for a plethora of libraries. My conclusion for the build
>>> system
Singling out just one tiny corner of all that for a passing remark:
Jason Newton (1 August 2018 10:24)
> One of the things I like about the way bazel keeps this is I can jump
> back and forth between an optimized build and a full debug build (for
> example) - they don't erase eachother
This is ea
On Mon, Jul 30, 2018 at 1:30 PM Matthew Woehlke
wrote:
>
> On 2018-07-21 19:52, Jason Newton wrote:
> > I wanted to mention that this is on my mind alot for a few years days
> > as a user for a plethora of libraries. My conclusion for the build
> > system with the brightest future is bazel [...]
On 31 July 2018 at 22:33, Thiago Macieira wrote:
> On Tuesday, 31 July 2018 11:43:49 PDT Scott Bloom wrote:
>> Just a note.. for CMake, I find the -debug-output -trace and -trace-expand
>> as useful as the -d and -d -d .
>>
>> One other thing I use all the time for dependency analysis, is the -gra
On Tuesday, 31 July 2018 11:43:49 PDT Scott Bloom wrote:
> Just a note.. for CMake, I find the -debug-output -trace and -trace-expand
> as useful as the -d and -d -d .
>
> One other thing I use all the time for dependency analysis, is the -graphviz
> switch.
Thanks, noted. I didn't know about tho
-Original Message-
From: Development On
Behalf Of Thiago Macieira
Sent: Tuesday, July 31, 2018 11:41
To: development@qt-project.org
Subject: Re: [Development] Qt 6 buildsystem support requirements
On Tuesday, 31 July 2018 11:15:50 PDT Ville Voutilainen wrote:
> This provoke
On Tuesday, 31 July 2018 11:15:50 PDT Ville Voutilainen wrote:
> This provoked a thought in me, a way to make qbs worth all its effort:
> make debugging
> a build so staggeringly ridiculously good that it becomes attractive
> to use it. I don't know
> what debugging builds done with python-based bu
On 31 July 2018 at 20:49, Thiago Macieira wrote:
> I know CMake meets these requirements, but it has other problems and the fact
> that it currently does not build Qt. On that front, qbs is ahead. But qbs has
> a shorter track record. Since we're not switching buildsystems in the next 2
> years, t
On Tuesday, 31 July 2018 09:35:42 PDT Lisandro Damián Nicanor Pérez Meyer
wrote:
> > I would say the only two options in the running are qbs and CMake.
>
> Just for curiosity I checked qbs' reverse dependencies (packages that
> require qbs installed in order to be built) in Debian. We currently o
> I would say the only two options in the running are qbs and CMake.
About this, I don't know if C++ community acceptance is a criterion, but :
https://github.com/search?q=cmake
https://github.com/search?q=qbs
On Tue, Jul 31, 2018 at 4:41 PM, Thiago Macieira
wrote:
> On Monday, 30 July 2018
El martes, 31 de julio de 2018 11:41:15 -03 Thiago Macieira escribió:
> On Monday, 30 July 2018 23:11:54 PDT Denis Shienkov wrote:
> > As for me, is it prefferable variant will be *QBS* (it is best from the
> > best).
> >
> > I'm do not like nor CMake, nor QMake, nor Autotools, nor something else.
On Monday, 30 July 2018 23:11:54 PDT Denis Shienkov wrote:
> As for me, is it prefferable variant will be *QBS* (it is best from the
> best).
>
> I'm do not like nor CMake, nor QMake, nor Autotools, nor something else.
I would say the only two options in the running are qbs and CMake.
--
Thiago
> On 31 Jul 2018, at 09:41, Иван Комиссаров wrote:
>
> QBS generates Qt Modules file depending on the information that QMake
> provides about modules installed in the system to make sure you won;t be able
> to import module that doesn’t exist on your system.
Files that were dynamically create
QBS generates Qt Modules file depending on the information that QMake provides
about modules installed in the system to make sure you won;t be able to import
module that doesn’t exist on your system.
According to the fact that you can have multiple versions of Qt (i have 3 Qt
versions on my Lin
> On 30 Jul 2018, at 22:30, Matthew Woehlke wrote:
>
> On a related note, "hermetic builds" is pretty ironic. Your *build*
> might be hermetic, but bazel itself is *far* from... it's very reliant
> on putting all its garbage in "magic locations" in your home directory,
> unlike most build tools
Hi guys,
Is there are any list of options from which it is possible to choose?
As for me, is it prefferable variant will be *QBS* (it is best from the
best).
I'm do not like nor CMake, nor QMake, nor Autotools, nor something else.
BR,
Denis
___
On 2018-07-21 19:52, Jason Newton wrote:
> I wanted to mention that this is on my mind alot for a few years days
> as a user for a plethora of libraries. My conclusion for the build
> system with the brightest future is bazel [...]
No. Just, *no*.
Persistent build server? Java? No, thanks.
Mayb
El domingo, 22 de julio de 2018 18:54:14 -03 Kevin Kofler escribió:
> Thiago Macieira wrote:
> > Specifically, the problem with TensorFlow is that it wants to download its
> > dependencies when you compile it, then compile them at the same time. That
> > can't work because the build servers don't h
Thiago Macieira wrote:
> Specifically, the problem with TensorFlow is that it wants to download its
> dependencies when you compile it, then compile them at the same time. That
> can't work because the build servers don't have internet connectivity.
+1, this is also a hard, non-negotiable requirem
On Sunday, 22 July 2018 10:34:13 PDT Tobias Hunger wrote:
> > "More than one" would be quite a challenge.
>
> We can not expect people to drop their preferred set of tools to work on
> Qt. That is a sure-fire way to reduce contributions from outside of our
> core community.
Sure, but we compare th
Hi Thiago,
On Sun, Jul 22, 2018, 17:35 Thiago Macieira
wrote:
> > A) works with IDE(s) -- preferably more than one
>
> Hello Tobias
>
> The fact that we have an IDE of ours means this one should be reasonably
> easy
> to address, as we can make that IDE work with the tool. So long as the
> tool
On Sun, Jul 22, 2018, 12:58 Иван Комиссаров wrote:
> But only qmake works fine with new clang model, other build systems pass
> incorrect parameters to clang so it can’t compile my files (code model
> complains about missing std:: classes/functions, however the code compiles
> so project file is
On Sunday, 22 July 2018 03:57:37 PDT Иван Комиссаров wrote:
> That’s it. You pointing too much attention to the Linux distros and
> maintainers, which is very important, but you are using wrong arguments.
> Give those maintainers a good tool and they will be happy. And the «good
> tool» is not the
On Sunday, 22 July 2018 01:57:59 PDT Tobias Hunger wrote:
> All these are very reasonable to ask for. I personally would like to add
> the following point for consideration:
>
> 4) Toolable
>
> A) works with IDE(s) -- preferably more than one
Hello Tobias
The fact that we have an IDE of ours m
On Sunday, 22 July 2018 02:20:04 PDT Christian Gagneraud wrote:
> > It's EXACTLY the reason our seniormost engineers spent three days trying
> > to
> > upgrade TensorFlow in Clear Linux. That's not your junior guy who only
> > knows how to run "npn install". We're talking about people who had been
On Sunday, 22 July 2018 03:31:42 PDT Kevin Kofler wrote:
> PS: In addition, https://bazel.build/ itself describes Bazel as "Beta". In
> particular, "Bazel is not yet covered by a deprecation policy, may be
> subject to backward-incompatible changes, and is missing some features."
>
> I do not thin
El dom., 22 de jul. de 2018 06:40, Christian Gagneraud
escribió:
> On 22 July 2018 at 00:42, Kevin Kofler wrote:
> > Bogdan Vatra via Development wrote:
> >> Anyway IMHO is more important to have a clean, nice and easy to use
> syntax
> >> and to be tooling friendly than 1.b.
> >
> > A custom bu
On Sun, Jul 22, 2018 at 3:11 AM Kevin Kofler wrote:
>
> Jason Newton wrote:
> > My conclusion for the build system with the brightest future is bazel
>
> Looking at this, this build system depends on Python AND Java! They ship
> binaries with everything bundled, but that is a huge bloat (and it al
Hi,
În ziua de duminică, 22 iulie 2018, la 12:18:06 EEST, Tobias Hunger a scris:
> On Sat, Jul 21, 2018, 14:49 Jean-Michaël Celerier <
>
> jeanmichael.celer...@gmail.com> wrote:
> > +1, I was flabbergasted when the big objection against CMake in Qt 6
> > boiled down to "it does not supports all th
Hi,
În ziua de duminică, 22 iulie 2018, la 12:11:44 EEST, Tobias Hunger a scris:
> On Sat, Jul 21, 2018, 07:38 Bogdan Vatra via Development <
>
> development@qt-project.org> wrote:
> > You really hate QBS don't you ? :)
>
> Do you have so few arguments for qbs that you need to appeal to emotions?
Sounds like you have a configuration problem in Qt Creator. I've been using
qtc with the clang code model and CMake projects for over a year on various
C++11/14/17 projects and everything works fine.
$ echo '#include \nint main() { std::string_view s("foo"); }'
> main.cpp ; echo 'project(foo CXX)\
> 21 июля 2018 г., в 23:04, Thiago Macieira
> написал(а):
>
> On Saturday, 21 July 2018 10:39:49 PDT Иван Комиссаров wrote:
>> 1. IDE integration. I really need the IDE know the correct CXX flags for
>> each separate file in my project - that is includes, c++ version and so on.
>> Currently i’m
I wrote:
> Bazel is still fairly new and adoption is low, especially in the Free
> Software world.
PS: In addition, https://bazel.build/ itself describes Bazel as "Beta". In
particular, "Bazel is not yet covered by a deprecation policy, may be
subject to backward-incompatible changes, and is mis
Jason Newton wrote:
> My conclusion for the build system with the brightest future is bazel
Looking at this, this build system depends on Python AND Java! They ship
binaries with everything bundled, but that is a huge bloat (and it also does
not help GNU/Linux distributions, which will want to u
My bad, I thought that you were counting in Kloc of code, not in kilobytes.
That's in my opinion a weird metric for measuring code since indenting
with, say, 4 spaces instead of 1 tab would certainly end up giving wild
differences.
cloc cmake/Source/cmQt*
--
On Sun, Jul 22, 2018, 10:20 AM Christian Gagneraud wrote:
> On 22 July 2018 at 14:05, Thiago Macieira
> wrote:
> > On Saturday, 21 July 2018 16:52:44 PDT Jason Newton wrote:
> >> -Ability to build external libraries from source or pull in binary
> >> libraries
> >
> > This is not a feature. It's
On 22 July 2018 at 00:42, Kevin Kofler wrote:
> Bogdan Vatra via Development wrote:
>> Anyway IMHO is more important to have a clean, nice and easy to use syntax
>> and to be tooling friendly than 1.b.
>
> A custom build system is always a major pain point for distributions. A
> circular dependenc
On 22 July 2018 at 14:05, Thiago Macieira wrote:
> On Saturday, 21 July 2018 16:52:44 PDT Jason Newton wrote:
>> -Ability to build external libraries from source or pull in binary
>> libraries
>
> This is not a feature. It's a misfeature.
>
> It's EXACTLY the reason our seniormost engineers spent
On Sat, Jul 21, 2018, 14:49 Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com> wrote:
> +1, I was flabbergasted when the big objection against CMake in Qt 6
> boiled down to "it does not supports all the architectures that Qt
> supports",
>
IIRC the bid showstopper was that CMake does not su
On Sat, Jul 21, 2018, 07:38 Bogdan Vatra via Development <
development@qt-project.org> wrote:
> You really hate QBS don't you ? :)
Do you have so few arguments for qbs that you need to appeal to emotions? :)
Anyway IMHO is more important to have a clean, nice and easy to use syntax
> and
> to b
Hi Thiago,
On Sat, Jul 21, 2018, 04:36 Thiago Macieira
wrote:
> [...] I'd like to add the following
> extra requirements to the buildsystem we choose to use. This is in
> addition to
> the functionality requirements.
>
> [...]
>
1) Ease of obtention
2) Track record
>
> 3) Community support
>
On Saturday, 21 July 2018 16:52:44 PDT Jason Newton wrote:
> -Ability to build external libraries from source or pull in binary
> libraries
This is not a feature. It's a misfeature.
It's EXACTLY the reason our seniormost engineers spent three days trying to
upgrade TensorFlow in Clear Linux. Tha
On Saturday, 21 July 2018 10:39:49 PDT Иван Комиссаров wrote:
> 1. IDE integration. I really need the IDE know the correct CXX flags for
> each separate file in my project - that is includes, c++ version and so on.
> Currently i’m using a generated CMake file at my work and the integration
> with Q
I think this is an incredibly important issue! Sorry if this creates
a new thread, I'm hopping on the ML and I don't have any previous
mails to reply-to.
I wanted to mention that this is on my mind alot for a few years days
as a user for a plethora of libraries. My conclusion for the build
syste
Иван Комиссаров wrote:
> I have several other requirements for the buildsystem.
> 1. IDE integration. I really need the IDE know the correct CXX flags for
> each separate file in my project - that is includes, c++ version and so
> on. Currently i’m using a generated CMake file at my work and the
>
El vie., 20 de jul. de 2018 23:36, Thiago Macieira <
thiago.macie...@intel.com> escribió:
> Hello
>
> Having spent far too much time trying to figure out why crappy
> buildsystems
> cause failures in distros (like TensorFlow or libvpx - see
> https://plus.google.com/+ThiagoMacieira/posts/DqTKdRGfu
What you wrote reminds me how government officials spent budget money for the
new cars in my country. They write specific tender documentation that fits only
one car, say Chevrolet Tahoe (for example, "the car that fits 9 people, has
leather interior and has the power of 200hp»). The argumentat
On Sat, Jul 21, 2018 at 4:42 PM, Jean-Michaël Celerier
wrote:
> That's fairly disingenuous, if not blatantly false. There are, like, 6 .cpp
> files in the CMake repo which provide the Qt-specific commands :
> https://github.com/Kitware/CMake/tree/master/Source (grep for cmQt).
>
What is disingenu
Il 21/07/2018 17:42, Jean-Michaël Celerier ha scritto:
Besides... why would it matter that they are implemented in C++ instead
of cmake-lang ? If anything, CMake's automoc is in my experience much
faster to process the whole repo.
Playing devil's advocate, please bear with me:
Because it mak
On Saturday, 21 July 2018 05:42:08 PDT Kevin Kofler wrote:
> Bogdan Vatra via Development wrote:
> > Anyway IMHO is more important to have a clean, nice and easy to use syntax
> > and to be tooling friendly than 1.b.
>
> A custom build system is always a major pain point for distributions. A
> cir
On Saturday, 21 July 2018 00:18:40 PDT Bogdan Vatra via Development wrote:
> I'm not trying to sell GN here, because from my experience, Google folks are
> quite difficult to work with and not very open to changes.
Yes, they are. My email started with relating problems trying to build
TensorFlow.
On Friday, 20 July 2018 19:35:48 PDT Thiago Macieira wrote:
> c) Must not require too-recent version in order to compile Qt. The versions
> found in ( a) must be sufficient to build Qt 6.0 and this must continue
> throughout Qt 6's lifetime.
Clarification: I don't mean the versions found at 6.0's
That's fairly disingenuous, if not blatantly false. There are, like, 6 .cpp
files in the CMake repo which provide the Qt-specific commands :
https://github.com/Kitware/CMake/tree/master/Source (grep for cmQt).
Besides... why would it matter that they are implemented in C++ instead of
cmake-lang ?
1 - 100 of 113 matches
Mail list logo
