[Qbs] Unexpected behavior of MSVC generator

[Иван Комиссаров]

Anyway, I still don’t see the problem - QBS can emulate the build process for that an IDE normally does, placing the artifacts in the exact places where IDE would place them. At least, that’s how (unfinished) Xcode generator works - it builds the app to a generic folder and then creates symlinks to the artifacts so XCode can find them (symlinks are located in places where Xcode outs binaries during «native» build. Why this approach won’t work for bare metal IDE?

> 18 февр. 2019 г., в 20:38, Denis Shienkov <denis.shienkov at gmail.com> написал(а):
> 
> > 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'.
> 
> But:
> - 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:
>>>> For c++ - yes. Imagine a pure javascript rule that doesn’t invoke any
>>> «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.
>> 
>> Andre'
> _______________________________________________
> Qbs mailing list
> Qbs at qt-project.org
> https://lists.qt-project.org/listinfo/qbs