Re: [Qbs] dependency tracking
>> "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
Re: [Qbs] Why was protobuf.outputDir removed
As I said before, I have no objections to bring the property back.
Just add a test so we know why we need this property and add custom tags for
the generated files to separate them from the other header files.
Ivan.
> 16 сент. 2020 г., в 08:27, Kai Dohmen via Qbs написал(а):
>
> 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 Иван Комиссаров
> mailto: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
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] dependency tracking
On Tue, 15 Sep 2020 22:10:13 +0500 Dan Pat wrote: > "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. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
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
