Re: [Qbs] Why was protobuf.outputDir removed
Hello Ivan, the use-case of installation arises from encapsulating the proto files into a single library. I do this because then it is easier for me to use the proto-stuff in different applications. Since I started to use conan to track dependencies I needed to compile and install the static library for use in the consuming application. I would rather append the proto files to an products source files If there is a (non hacky) way to it (with conan), Kai Am Di., 15. Sept. 2020 um 09:41 Uhr schrieb Иван Комиссаров < abba...@gmail.com>: > 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
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