Re: [Qbs] dependency tracking
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
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] Why was protobuf.outputDir removed
This won’t work in case of the protoc - the generated tree does not always match the tree in the source and it depends on the order of the -I flags passed to protoc. Ivan > 15 сент. 2020 г., в 10:35, Oswald Buddenhagen > написал(а): > > On Tue, Sep 15, 2020 at 09:00:50AM +0200, Kai Dohmen via Qbs wrote: >> Furthermore when installing the generated header files I cannot use the >> Groups property installSourceBase to match the installed directory >> structure to the proto files ones. >> > that's actually an interesting one. the general idea is to get rid of > accessible output dirs to make the build dirs as opaque as possible. > however, this obviously defies installSourceBase usage with generated files > (the original use case was to install trees of data files that are not > generated). i think the way out would be finding the *sources* of the > installed artifacts (if necessary, recursively), as their layout is actually > controllable by the user, and consequently expect the base to point into the > source tree. this shall fail if an artifact has multiple primary sources > coming from different directories. > ___ > 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] Why was protobuf.outputDir removed
On Tue, Sep 15, 2020 at 09:00:50AM +0200, Kai Dohmen via Qbs wrote: Furthermore when installing the generated header files I cannot use the Groups property installSourceBase to match the installed directory structure to the proto files ones. that's actually an interesting one. the general idea is to get rid of accessible output dirs to make the build dirs as opaque as possible. however, this obviously defies installSourceBase usage with generated files (the original use case was to install trees of data files that are not generated). i think the way out would be finding the *sources* of the installed artifacts (if necessary, recursively), as their layout is actually controllable by the user, and consequently expect the base to point into the source tree. this shall fail if an artifact has multiple primary sources coming from different directories. ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Why was protobuf.outputDir removed
Hello, Kai
First of all, the property was not removed but was made «private» and is now
called _outputDir. You can still override it or read it.
The reason why it was removed is that I didn’t see valid use-cases for that.
For example, to export include paths you should do something like that:
StaticLibrary {
files: [«a.cpp», «b.proto»]
Depends { name: «protobuf.cpp» }
Export {
Depends { name: «protobuf.cpp» } // this should export protobuf.cpp
properties, including cpp.IncludePath
}
}
However, your second use-case (installation) is totally new to me and it seems
that you need to read this property.
Unless someone can suggest a better solution, feel free to upload a patch to
return the property.
You might also want to assign custom tags for generated files (e.g.
«proto_hpp», «proto_cpp») to make filtering more fine-grained and avoid
overlapping with other headers.
Ivan
> 15 сент. 2020 г., в 09:00, Kai Dohmen via Qbs написал(а):
>
> Hello,
>
> the subject states my Question.
> Normally I create a static library from proto files. This static library can
> be linked into different applications. This really comes in handy when using
> conan.
> But since protobuf.outputDir was removed I cannot set the Exported
> includePaths dir properly.
> Furthermore when installing the generated header files I cannot use the
> Groups property installSourceBase to match the installed directory structure
> to the proto files ones.
>
> What is the right way of using proto files as a library? Should they get
> compiled or should they append to the depending products source files?
>
> Thanks,
> Kai
> ___
> 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] Why was protobuf.outputDir removed
Hello, the subject states my Question. Normally I create a static library from proto files. This static library can be linked into different applications. This really comes in handy when using conan. But since protobuf.outputDir was removed I cannot set the Exported includePaths dir properly. Furthermore when installing the generated header files I cannot use the Groups property installSourceBase to match the installed directory structure to the proto files ones. What is the right way of using proto files as a library? Should they get compiled or should they append to the depending products source files? Thanks, Kai ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
