Re: [Qbs] Cpp module for WebAssembly
On 27.10.2020 12:27, Dan Pat wrote:
> 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.
If it is only for development on your machine and your ownly goal is to put
your module under version control in your product directory, then you can do:
import "/path/to/qbs/modules/cpp/GenericGcc.qbs" as GenericGcc
GenericGcc {
// hack hack hack
}
>
> 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.
This sounds fantastic! Keep on hacking and upload a patch soon. See
https://code.qt.io/cgit/qbs/qbs.git/tree/CONTRIBUTING.md
Richard
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] (no subject)
> > 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
Re: [Qbs] (no subject)
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] (no subject)
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
>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
>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
