[Qbs] Unexpected behavior of MSVC generator
denis.shienkov at gmail.com
Mon Feb 18 20:38:16 CET 2019
> One can argue the other way round, too: Why would A have to take care
of "native" export to B when B does not care for importing A?
Because - 'A' is an universal cross-platform tool, aka QBS. And 'B' - it
is usually a narrowly specialized vendor-specific tool.
And a tool 'B' does not known nothing about 'A'.
- tool 'B' has a better debugger than a tool 'A' and this debuger are
integrated only to the IDE of tool 'B'.
- tool 'B' has a worse IDE editor than a tool 'A' (e.g. QtC).
So, we just create a cross-platform project on a tool 'A' (on QBS) and
to generate required project for a tool 'B' , 'C' or something else to
use this generated project in that tools. It can be useful e.g. for
debugging purposes, or when a customer want to have a resulting project
sources in a "native" tool.
Of course, the developer can start developing a project using the
required target native tool 'B', 'C' and etc.. but usually, this tools
have an ugly IDE with a code editors (which causes a "vomiting reflex").
PS: I say about the bare-metal programming industry. It just a my
thoughts and wants. For me it would be a more comfortable to use the QtC
&& QBS with generators. :)
18.02.2019 22:11, André Pönitz пишет:
> On Sun, Feb 17, 2019 at 09:10:32PM +0300, Denis Shienkov wrote:
>> «compiler» (like cl or javac) but converts some input to output using qbs
>> itself. How that custom rule would like?
>> But we speak about c/c++ :)
>>> What are pros?
>> Pros are than I can use then a generated 'native' project on hosts without
>> of QBS (just use that 'native' IDE && tools)! F.e. using a 'native'
>> debugger and etc.
> One can argue the other way round, too: Why would A have to take care of
> "native" export to B when B does not care for importing A?
> The soft spot in such cases of interoperability is typically somewhere
> in between: Both sides should care somewhat of the other.
More information about the Qbs