[Qbs] (no subject)

[Dan Pat]

Hello. A bunch of Products must be built using a certain set of "cpp"
flags. I created a special Module (later referred to as "CppFlags"")
containing those flags and had these Products depend upon CppFlags. There
are other Modules that the Products depend on, and some of these Modules
contain Rules that generate cpp files, which also must be built using the
above mentioned set of "cpp" flags. But it seems that since such generator
Modules do not explicitly depend on CppFlags, they do not pick up the
required flags. So the question is how do I make sure that a certain set of
flags is applied to any cpp file built in the context of a Product?
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Grouping files

[Dan Pat]

Spot on. Thanks a lot!

On Wed, 24 Mar 2021 at 13:31, Jochen Ulrich 
wrote:

> How about setting the `excludeFiles` conditionally?
> So something like this:
>
>
>
> Group {
>
> files: "*.cpp"
>
> prefix: "**/"
>
> excludeFiles: qbs.targetOS.contains("linux") ? "*_windows.cpp" :
> "*_linux.cpp"
>
> }
>
>
>
> Not sure if this works, though.
>
>
>
> Best
>
> Jochen
>
>
>
> *Von: *Qbs  im Auftrag von Dan Pat <
> danni...@gmail.com>
> *Datum: *Mittwoch, 24. März 2021 um 08:05
> *An: *qbs 
> *Betreff: *[Qbs] Grouping files
>
> Hi. I have a complex directory structure where cpp/h files reside. To add
> these files to the project, I would normally create a Group and  specify
> the top level directory using a wild card '**'  - saves me a lot of typing.
> Now, I am faced with a task of conditionally selecting implementation files
> for different platform targets, that is  files '*_linux.cpp' must be chosen
> for the linux target and '*_windows.cpp' - for the windows target. There
> are just a couple of such places, deep down the directory hierarchy, where
> such separation is needed, not that this is a regular thing.  I don't know
> of any way to exclude files using a wildcard, I guess that's what the
> "excludeFiles" property is for. But using this property means I have to
> create another Group to deal with implementation files which will be shown
> separately in the project tree view. If what you want is a single view of
> the directory structure with the appropriate implementation files shown
> (and it's what I want) you need to abandon the wildcard description (to a
> degree depending on the actual directory structure and location of
> implementation files) and list some directories manually (a lot, in may
> case). So, do I accept it and live with it? Or, maybe there's an approach I
> am missing?
>
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

[Qbs] Grouping files

[Dan Pat]

Hi. I have a complex directory structure where cpp/h files reside. To add
these files to the project, I would normally create a Group and  specify
the top level directory using a wild card '**'  - saves me a lot of typing.
Now, I am faced with a task of conditionally selecting implementation files
for different platform targets, that is  files '*_linux.cpp' must be chosen
for the linux target and '*_windows.cpp' - for the windows target. There
are just a couple of such places, deep down the directory hierarchy, where
such separation is needed, not that this is a regular thing.  I don't know
of any way to exclude files using a wildcard, I guess that's what the
"excludeFiles" property is for. But using this property means I have to
create another Group to deal with implementation files which will be shown
separately in the project tree view. If what you want is a single view of
the directory structure with the appropriate implementation files shown
(and it's what I want) you need to abandon the wildcard description (to a
degree depending on the actual directory structure and location of
implementation files) and list some directories manually (a lot, in may
case). So, do I accept it and live with it? Or, maybe there's an approach I
am missing?
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] (no subject)

[Dan Pat]

Thanks, that seems to work.

On Mon, 11 Jan 2021 at 14:56, Christian Kandeler 
wrote:

> On 1/11/21 9:23 AM, Dan Pat wrote:
> > Hi. I have a question about making third-party libraries
> available/visible
> > when running programs from qtcreator.  We have a number of prebuilt
> > libraries in the source tree which are currently wrapped in Modules. The
> > modules contain include/library paths, so any depending products build
> > fine, but fail to run because the runtime is unable to locate the library
> > files. One way (our current approach) to solve the problem is to list
> those
> > files in Modules under Group items, make them installable to
> "install-root"
> > location and make that location searchable by the dynamic linker (under
> > Windows it is the default behaviour). It works but leads to an
> > inconvenience - these files now show up as being part of the depending
> > products. I know that this is by design, but in this case library files
> > being listed N times in N dependent products look strange at the least.
> Can
> > anyone recommend a nicer approach?
>
> In the groups containing the library files, set the filesAreTargets
> property to true.
>
>
> Christian
>
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
>
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

[Qbs] (no subject)

[Dan Pat]

Hi. I have a question about making third-party libraries available/visible
when running programs from qtcreator.  We have a number of prebuilt
libraries in the source tree which are currently wrapped in Modules. The
modules contain include/library paths, so any depending products build
fine, but fail to run because the runtime is unable to locate the library
files. One way (our current approach) to solve the problem is to list those
files in Modules under Group items, make them installable to "install-root"
location and make that location searchable by the dynamic linker (under
Windows it is the default behaviour). It works but leads to an
inconvenience - these files now show up as being part of the depending
products. I know that this is by design, but in this case library files
being listed N times in N dependent products look strange at the least. Can
anyone recommend a nicer approach?
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] (no subject)

[Dan Pat]

 Hi, Ivan. The work is incomplete and I have insufficient knowledge to go
on without investing time which I don't have right now, sorry.  Maybe, I
could reach you over a private channel to share my work and the issues I am
up against. What do you think?

вт, 15 дек. 2020 г. в 15:41, Иван Комиссаров :

> Hello, Dan! Any chance you publish your solution? I am interested in wasm
> support as well
>
> Ivan
>
> >
> > The goal is to get qbs projects compiled to WebAssembly using the
> emscripten toolchain (and Qt WebAssembly). As for upstreaming: I have
> managed to come up with a working but hacky solution (a small test project)
> which I believe has room for improvement.
> >
> >
>
>
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] (no subject)

[Dan Pat]

>
> You can provide your own cpp implementation by overriding the search
> path, but I don't see how you would be able to refer to the contents of
> the original directory. Note that the files there are implementation
> details and their presence and names cannot be relied upon. It's not a
> supported use case to derive from these items. So to achieve what you
> want, you'd have to copy the qbs module files you want to extend


My fears confirmed.

Out of curiosity: Which special features does it implement and why are
> they not suitable for upstreaming?


The goal is to get qbs projects compiled to WebAssembly using the
emscripten toolchain (and Qt WebAssembly). As for upstreaming: I have
managed to come up with a working but hacky solution (a small test project)
which I believe has room for improvement.

вт, 27 окт. 2020 г. в 15:58, Christian Kandeler :

> On 10/27/20 11:47 AM, Dan Pat wrote:
> > Hi, I have created a Module that inherits GenericGcc
>
>
> Out of curiosity: Which special features does it implement and why are
> they not suitable for upstreaming?
>
>
> > and hence is loaded as a "cpp" module when certain conditions are met.
> > During development the module file was located in the module directory
> > of the QtCreator installation. But I would like to move it to the qbs
> > module directory inside our project (using qbsSearchPaths). It is
> > desirable that the module be addressable by "cpp" name to avoid
> > changing the project files. To try to achieve that I created a
> > directory called "cpp" in the project module directory hoping that the
> > contents of this directory and the contents of the QtCreator qbs
> > module directory will somehow merge together. But it didn't work as
> > you might guess). Any ideas how to pull that off without having to
> > keep a copy of the file in the QtCreator qbs module directory?
>
>
> You can provide your own cpp implementation by overriding the search
> path, but I don't see how you would be able to refer to the contents of
> the original directory. Note that the files there are implementation
> details and their presence and names cannot be relied upon. It's not a
> supported use case to derive from these items. So to achieve what you
> want, you'd have to copy the qbs module files you want to extend.
>
>
>
> Christian
>
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
>
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

[Qbs] (no subject)

[Dan Pat]

Hi, I have created a Module that inherits GenericGcc and hence is loaded as
a "cpp" module when certain conditions are met. During development the
module file was located in the module directory of the QtCreator
installation. But I would like to move it to the qbs module directory
inside our project (using qbsSearchPaths). It is desirable that the module
be addressable by "cpp" name to avoid changing the project files. To try to
achieve that I created a directory called "cpp" in the project module
directory hoping that the contents of this directory and the contents of
the QtCreator qbs module directory will somehow merge together. But it
didn't work as you might guess). Any ideas how to pull that off without
having to keep a copy of the file in the QtCreator qbs module directory?
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] dependency tracking

[Dan Pat]

>It's expected that the generator won't re-run, because the dependency
parsing happens when building a cpp file.
So, I guess, this explanation must be correct.

вт, 27 окт. 2020 г. в 15:22, Dan Pat :

> >As Christian said: The problem is that the cpp scanner is triggered by the
> >generated cpp file, but there is no connection to the testinput.h because
> >your cpp files is not including it.
>
> Sorry for getting back to this so late. I have missed a very important
> detail - the generated cpp files do include the headers from which they are
> generated. To illustrate, I followed Richard's advice and prepended the cpp
> file with the line " #include "testinput.h" ". The modified Module
> definition (never mind the hardcoded string - it's just a test):
>
> Module {
>
> id: testgen
>
>
> Rule {
>
> inputs: ["genxx"]
>
> Artifact {
>
> id: artifact
>
> filePath: FileInfo.path(input.filePath)  + "/" + 
> FileInfo.baseName(input.filePath) + "-gen.cpp"
>
> fileTags: ["cpp"]
>
> }
>
> prepare: {
>
>
> var cmd = new JavaScriptCommand();
>
> cmd.description =  'Running test generator';
>
> cmd.sourceCode = function(){
>
> var file = new TextFile(output.filePath, TextFile.WriteOnly);
>
> file.write("#include \"testinput.h\"\r\n const int c = 5;");
>
> file.close();
>
>
> }
>
>
> return cmd;
>
>
> }
>
> }
>
> }
>
>
> But the observed behavior is still the same.
>
>
> чт, 17 сент. 2020 г. в 04:25, Richard Weickelt :
>
>> >> "testinput.h" file contains "#include "a.h" directive. Changing
>> >> testinput.h results in a generator run followed by a C++ compiler run.
>> >> Changing a.h results in no action, although in this case the generator
>> >> is intended to reprocess its input.
>> >
>> > It's expected that the generator won't re-run, because the dependency
>> > parsing happens when building a cpp file, i.e. all the headers are
>> > dependencies of the object file, and the header files themselves are
>> only
>> > "passed through" by the scanning process. Though you might be able to
>> > cheat by setting up a dummy cpp file that includes the top-level header
>> > and making that an input to the generator rule.
>>
>> As Christian said: The problem is that the cpp scanner is triggered by the
>> generated cpp file, but there is no connection to the testinput.h because
>> your cpp files is not including it.
>>
>> If you could add the following lines to your generated cpp file:
>>
>> #ifdef IGNORED
>> #include "testinput.h"
>> #endif
>>
>> then this should be enough to make the cpp scanner think that you are
>> actually including testinput.h and hence, it will see and track a.h as
>> well.
>>
>> Richard
>> ___
>> Qbs mailing list
>> Qbs@qt-project.org
>> https://lists.qt-project.org/listinfo/qbs
>>
>
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] dependency tracking

[Dan Pat]

>As Christian said: The problem is that the cpp scanner is triggered by the
>generated cpp file, but there is no connection to the testinput.h because
>your cpp files is not including it.

Sorry for getting back to this so late. I have missed a very important
detail - the generated cpp files do include the headers from which they are
generated. To illustrate, I followed Richard's advice and prepended the cpp
file with the line " #include "testinput.h" ". The modified Module
definition (never mind the hardcoded string - it's just a test):

Module {

id: testgen


Rule {

inputs: ["genxx"]

Artifact {

id: artifact

filePath: FileInfo.path(input.filePath)  + "/" +
FileInfo.baseName(input.filePath) + "-gen.cpp"

fileTags: ["cpp"]

}

prepare: {


var cmd = new JavaScriptCommand();

cmd.description =  'Running test generator';

cmd.sourceCode = function(){

var file = new TextFile(output.filePath, TextFile.WriteOnly);

file.write("#include \"testinput.h\"\r\n const int c = 5;");

file.close();


}


return cmd;


}

}

}


But the observed behavior is still the same.


чт, 17 сент. 2020 г. в 04:25, Richard Weickelt :

> >> "testinput.h" file contains "#include "a.h" directive. Changing
> >> testinput.h results in a generator run followed by a C++ compiler run.
> >> Changing a.h results in no action, although in this case the generator
> >> is intended to reprocess its input.
> >
> > It's expected that the generator won't re-run, because the dependency
> > parsing happens when building a cpp file, i.e. all the headers are
> > dependencies of the object file, and the header files themselves are only
> > "passed through" by the scanning process. Though you might be able to
> > cheat by setting up a dummy cpp file that includes the top-level header
> > and making that an input to the generator rule.
>
> As Christian said: The problem is that the cpp scanner is triggered by the
> generated cpp file, but there is no connection to the testinput.h because
> your cpp files is not including it.
>
> If you could add the following lines to your generated cpp file:
>
> #ifdef IGNORED
> #include "testinput.h"
> #endif
>
> then this should be enough to make the cpp scanner think that you are
> actually including testinput.h and hence, it will see and track a.h as
> well.
>
> Richard
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
>
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] dependency tracking

[Dan Pat]

 Probably, I haven't made myself clear enough. Here's an example setup.
This is a dummy generator's module definition:

import qbs

import qbs.FileInfo

import qbs.TextFile


Module {

id: testgen


Rule {

inputs: ["genxx"]

Artifact {

id: artifact

filePath: FileInfo.path(input.filePath)  + "/" +
FileInfo.baseName(input.filePath) + "-gen.cpp"

fileTags: ["cpp"]

}

prepare: {


var cmd = new JavaScriptCommand();

cmd.description =  'Running test generator';

cmd.sourceCode = function(){

var file = new TextFile(output.filePath, TextFile.WriteOnly);

file.write("const int c = 5;");

file.close();


}


return cmd;


}

}

}

This is a dependent product's description:

import qbs
DynamicLibrary
{Group {name: "generatorInput"files: [
"testinput.h"]fileTags: ['hpp', "genxx"]}
Group {files:["a.h"]}
Depends {name: "cpp" }Depends {name: "testgen" }
}

"testinput.h" file contains "#include "a.h" directive. Changing
testinput.h results in a generator run followed by a C++ compiler run.
Changing a.h results in no action, although in this case the generator
is intended to reprocess its input.


вт, 15 сент. 2020 г. в 17:47, Dan Pat :

> Yes, the product does depend on the 'cpp' module. The include paths are
> fine, since the same header files are later used by the compiler. A little
> more detail: I use the Group language item to tag such headers
> appropriately.
> Assuming that the generator inputs tag is "genxx", the fileTags of the
> Group is  fileTags: ['hpp', 'genxx'].
>
> пн, 14 сент. 2020 г. в 20:52, Jochen Ulrich :
>
>> But it will only scan for dependent header files if the product using the
>> code generator depends on the `cpp` module and if the `cpp.includePaths`
>> are set up correctly, right?
>> Is this the case?
>>
>> Best
>> Jochen
>>
>>
>>
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] dependency tracking

[Dan Pat]

Yes, the product does depend on the 'cpp' module. The include paths are
fine, since the same header files are later used by the compiler. A little
more detail: I use the Group language item to tag such headers
appropriately.
Assuming that the generator inputs tag is "genxx", the fileTags of the
Group is  fileTags: ['hpp', 'genxx'].

пн, 14 сент. 2020 г. в 20:52, Jochen Ulrich :

> But it will only scan for dependent header files if the product using the
> code generator depends on the `cpp` module and if the `cpp.includePaths`
> are set up correctly, right?
> Is this the case?
>
> Best
> Jochen
>
>
>
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

[Qbs] dependency tracking

[Dan Pat]

Hi, I have a code generator using C++ *.h headers as its input. Everything
works fine for me except for dependency tracking. Since inputs are ordinary
include files they often include other include files which include other
include files etc. The problem is that when an include file included by the
input file changes the generator is not rerun, because, I guess,  it knows
nothing about it. The dependency extraction logic should be pretty much the
same as the one used by the built-in cpp scanner. Do I need to write my own
Scanner to do the job, or is there a way to somehow reuse the functionality
already implemented in the cpp module?
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

[Qbs] (no subject)

[Dan Pat]

Is qbs supposed to work with Qt WebAssembly (I cannot get it to work)? If
not, are there plans to add support?
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Applying cxxFlags to certain files

[Dan Pat]

I have checked out the solution and discovered an inconvenience. As it
stands, Artifacts are passed to the "cpp" module  with flags set by the
Product (and product imported Modules) in the context of which the
Artifacts are built. But as soon as I set the Artifact specific
"cpp.cxxFlags" , they seem to replace, instead of being appended to
(desired behaviour), the Product-wise flags. Can you suggest any clean way
to deal with this?


пт, 10 июл. 2020 г. в 14:34, Dan Pat :

> Ah, I was looking directly at it and still didn't notice the "cpp.
> cxxLanguageVersion" part. Thank you.
>
> пт, 10 июл. 2020 г. в 13:33, Richard Weickelt :
>
>> > Hi. I have a code generator, encapsulated in a dedicated Module,
>> producing
>> > c++ source files. The generator's artifacts are then picked up by the
>> > "cpp"
>> > module according to the rules. For such generated files (and for them
>> > only)
>> > I would like to pass certain flags to the compiler (to suppress certain
>> > warnings) but I cannot figure out how. Any ideas are welcome. Regards.
>>
>> Have a look at the code example here:
>> https://doc.qt.io/qbs/qml-qbslanguageitems-artifact.html
>>
>> If you use the outputArtifacts property of the Rule item instead, it
>> should work very similar:
>>
>> outputArtifacts: [{filePath: "myfile.cpp", fileTags: ["cpp"], cpp: {
>> someFlag: "value" }}]
>>
>>
>>
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Applying cxxFlags to certain files

[Dan Pat]

Ah, I was looking directly at it and still didn't notice the "cpp.
cxxLanguageVersion" part. Thank you.

пт, 10 июл. 2020 г. в 13:33, Richard Weickelt :

> > Hi. I have a code generator, encapsulated in a dedicated Module,
> producing
> > c++ source files. The generator's artifacts are then picked up by the
> > "cpp"
> > module according to the rules. For such generated files (and for them
> > only)
> > I would like to pass certain flags to the compiler (to suppress certain
> > warnings) but I cannot figure out how. Any ideas are welcome. Regards.
>
> Have a look at the code example here:
> https://doc.qt.io/qbs/qml-qbslanguageitems-artifact.html
>
> If you use the outputArtifacts property of the Rule item instead, it
> should work very similar:
>
> outputArtifacts: [{filePath: "myfile.cpp", fileTags: ["cpp"], cpp: {
> someFlag: "value" }}]
>
>
>
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

[Qbs] Applying cxxFlags to certain files

[Dan Pat]

Hi. I have a code generator, encapsulated in a dedicated Module, producing
c++ source files. The generator's artifacts are then picked up by the "cpp"
module according to the rules. For such generated files (and for them only)
I would like to pass certain flags to the compiler (to suppress certain
warnings) but I cannot figure out how. Any ideas are welcome. Regards.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] (no subject)

[Dan Pat]

Ok, I'll give it a try. Thank you!

пн, 2 дек. 2019 г., 22:27 Иван Комиссаров :

> Hello, Dan!
>
> It’s very sad to hear that QtC crashes for you.
>
> There’s one known issue in qbs which will be fixed with QtC 4.11 release.
> Can you please try release candidate if it works better or not?
> https://download.qt.io/development_releases/qtcreator/4.11/4.11.0-rc1/
>
> If release candidate still crashes, it might be worth compiling QtCreator
> manually in release with debug info - in that case, you will be able to
> attach a post-mortem debugger to it and see what happens
>
> PS: I am experiencing crashes on MacOS with QtC 4.10, but they are not
> related to qbs as far as I can see from the backtrace.
>
> > 2 дек. 2019 г., в 07:55, Dan Pat  написал(а):
> >
> > Hello, my qtcreator keeps crashing during reparsing of qbs projects
> (windows 10) - like twice or thrice a day. I'd really like to provide
> something along the lines of a log or a backtrace. Does such a log exist?
> AFAIK, to get a meaningfull backtrace for release builds under windows some
> sort of a backtrace creation facility has to be used. Does qtcreator/qbs
> have one in place?
> > ___
> > Qbs mailing list
> > Qbs@qt-project.org
> > https://lists.qt-project.org/listinfo/qbs
>
>
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

[Qbs] (no subject)

[Dan Pat]

Hello, my qtcreator keeps crashing during reparsing of qbs projects
(windows 10) - like twice or thrice a day. I'd really like to provide
something along the lines of a log or a backtrace. Does such a log exist?
AFAIK, to get a meaningfull backtrace for release builds under windows some
sort of a backtrace creation facility has to be used. Does qtcreator/qbs
have one in place?
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] (no subject)

[Dan Pat]

 > Who imposes that requirement and why?
Ok. Here's the thing. The project I am working on is based on Qt library
and consists of a bunch of libraries and executables with dependencies
between them expressed via a "Depends" language item. Plus there a number
of pre-built third-party libraries wrapped in Modules that some of the
Products within the project depend on. The project compiles and links and I
can run the executables just fine. Now comes Asan. We use a dynamic version
of Asan, since the CRT we use is dynamic (compilation with /MD option) .
The first step was to compile the project with sanitiser support. I managed
that, but I when tried to to run one of the tests, Asan reported an error.
I did a bit of research and figured out that the error was detected early
on during initialization of Qt DLLs. From what I have been able to find out
from Internet sources and through a  bit of testing I concluded that for
the sanitizer to work properly, the asan.dll must be loaded before any
other DLL in the process, specifically before the C runtime library,
because it needs to do some hotpatching in order to be able trace every
heap allocation call. In my case, seemingly, the asan.dll was loaded
somewhere in the middle of the DLL loading sequence when some of the heap
allocation has already been done resulting in a false error report. My
research revealed that in order for the asan.dll to be loaded first, its
import record in the binary IAT must come first, and for the import record
to come first the corresponding import library must come first on the
linker's list of imports. The asan library is contained in a Module, and I
have no idea how to get its import to the beginning of the linker's list.
Let's consider an example Product. Looking at an issued linker command:
Module dependencies are listed after any Product dependencies, any
libraries specified directly in cpp.dynamicLibraries (as an experiment, we
normally use Depends) come before Module dependencies but after any Product
dependencies, any cpp,linkerFlags (tried as a last resort) go the end of
the linker's arguments string.  I hope I have made myself clear, thank you.

чт, 28 нояб. 2019 г. в 21:37, Иван Комиссаров :

> It’s worth mentioning, that compiling with verbose flag can give some
> insight on what libraries/options clang-cl passes to the linker:
>
> clang-cl -v -fsanitize=address main.cpp
>
> Иван Комиссаров
>
> 28 нояб. 2019 г., в 17:23, Иван Комиссаров  написал(а):
>
> I did a small research and was able to compile a small example with
> clang-cl and asan.
> Here are the flags I had to set manually:
>
>
> cpp.optimization: "none"
>
> cpp.cxxFlags: [
>
> "/MT",
>
> "-fsanitize=address",
>
> ]
>
> cpp.linkerFlags: [
>
>
> "-wholearchive:C:\\Developer\\LLVM\\lib\\clang\\8.0.0\\lib\\windows\\clang_rt.asan-x86_64.lib",
>
>
> "-wholearchive:C:\\Developer\\LLVM\\lib\\clang\\8.0.0\\lib\\windows\\clang_rt.asan_cxx-x86_64.lib",
>
> ]
>
> cpp.staticLibraries: [
>
>
> "C:\\Developer\\LLVM\\lib\\clang\\8.0.0\\lib\\windows\\clang_rt.asan-x86_64.lib",
>
>
> "C:\\Developer\\LLVM\\lib\\clang\\8.0.0\\lib\\windows\\clang_rt.asan_cxx-x86_64.lib",
>
> ]
>
> Probably, we should add some support for that in Qbs...
> The problem is that qbs calls the linker directly (which is not the same
> clang-cl uses), maybe it’s worth using clang-cl for linking... or just add
> support for the usual clang with msvc ABI (I have plans for that for 1.16)
>
> Иван Комиссаров
>
> 28 нояб. 2019 г., в 15:53, Christian Kandeler 
> написал(а):
>
> On Thu, 28 Nov 2019 18:58:54 +0500
> Dan Pat  wrote:
>
> Hello. I am trying to use Asan in my project (windows 10, clang-cl).
>
> There's a requirement for the Asan import library to appear first in the
>
> linker's list of import libraries.
>
>
> Who imposes that requirement and why?
>
> I cannot seem to find a way to achieve this with qbs. Any suggestions?
>
>
> If you are sure it's really, really needed, you can use a Properties item
> in your product with e.g. cpp.dynamicLibraries (
> https://doc.qt.io/qbs/qml-qbslanguageitems-properties.html#overrideListProperties-prop),
> but then you will have to list *all* libraries there.
>
>
> Christian
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
>
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
>
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

[Qbs] (no subject)

[Dan Pat]

Hello. I am trying to use Asan in my project (windows 10, clang-cl).
There's a requirement for the Asan import library to appear first in the
linker's list of import libraries. I cannot seem to find a way to achieve
this with qbs. Any suggestions?
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs