Re: [Qbs] Unexpected behavior of MSVC generator

2019-02-18 Thread Иван Комиссаров
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

Re: [Qbs] Unexpected behavior of MSVC generator

2019-02-18 Thread Denis Shienkov
> 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

Re: [Qbs] Unexpected behavior of MSVC generator

2019-02-18 Thread 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++ :) > > >

Re: [Qbs] Unexpected behavior of MSVC generator

2019-02-17 Thread Denis Shienkov
Richard, > If you are using IAR then you probably appreciate the performant debugger and its ability to debug even highly optimized code. You are probably also used to IAR's editor and you can't live without it. Fair enough, but for that you don't need its native build tool, really. All you

Re: [Qbs] Unexpected behavior of MSVC generator

2019-02-17 Thread Denis Shienkov
> 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

Re: [Qbs] Unexpected behavior of MSVC generator

2019-02-16 Thread Richard Weickelt
Denis, > > What’s the point of implementing a rule for cpp files directly in the > solution and not implementing it for other cases? I don’t see any use cases. > > I'm don't understand a bit, what do you mean here? I think your view on the build process is too narrow. If all you care about is

Re: [Qbs] Unexpected behavior of MSVC generator

2019-02-16 Thread Иван Комиссаров
> 16 февр. 2019 г., в 19:04, Denis Shienkov > написал(а): > > Why is it a very challenging task? > > It is enough just to parse the QBS project, to take a compiler flags, > architectures, > defines and so on, and to create the MSVC project using that info. And then > the > Visual Studio

Re: [Qbs] Unexpected behavior of MSVC generator

2019-02-16 Thread Иван Комиссаров
I can comment. If you want a real generator, you should use cmake=) Being serious, it is not a recursion, it is a proxy - solution is the proxy for the IDE to call the build tool (which is QBS). Creating a «proper» solution that invokes compilers directly is a very challenging task… Imagine you

[Qbs] Unexpected behavior of MSVC generator

2019-02-16 Thread Denis Shienkov
Hi all, It was surprised for me, that a generated MSVC solution file has a build commands which are calls the QBS to build the generated MSVC solution... It is recursion!!! o_O WTF? But it has not a sense! If I want to build a project using the QBS, then I know that I will use the QBS! But