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] 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] 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
