-
Notifications
You must be signed in to change notification settings - Fork 163
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a Boost-friendly subproject case to CMakeLists #614
Conversation
Shall we unify the subproject and standalone configurations (e.g project name |
You can unify them if you like, but it's not required (or urgent.) |
Can this please be merged (incl. to master), so that I can remove |
obviously we can get it in . if not much to ask can we keep license on top of the file or is there any reason to keep the new configuration at top? |
Feel free to reorder the comments in any way you like. :-) |
0bf2b29
to
168dbf1
Compare
The comment at the top
is no longer strictly accurate, so you might either rephrase it or move it after the |
168dbf1
to
85838cd
Compare
I believe in the current state the library will not be usable due to missing IO dependency libraries and some builds indicate that internal boost dependencies might be missing too (align library is not in the target link libraries list but is used as include). @pdimov could you please point to a place where the expected behavior of compatible libraries is documented? Should they just provide the new target names? In that case I believe it would be better to carefully insert the new target declarations instead of doing if/else. I will fix the builds as well (probably have to gut the CI infrastructure, hope you don't mind @mloskot ). |
Not at the moment, sorry. But the behavior basically needs to be what |
What this PR does is allow Doing this "properly" will be more involved. It will be easier, and more "regular", if The CMakeLists file of Boost.Iostreams is a good reference example for a similar library: https://github.com/boostorg/iostreams/blob/9edd46fe730e2086675a91629287224bd92590ab/CMakeLists.txt But in either case, the general outline of At the moment, what I have as documentation is here: https://github.com/boostorg/cmake/blob/doc/developer/developer.md. It's still on a branch because it's not yet finished, but the parts that are there, are accurate. I hope it's of help. |
Thank you very much for a detailed explanation and examples. @lpranam, if I
will not be able to do in a better way, please merge what we have. I will
make a few attempts and come back to you.
…On Sun, 19 Sep 2021 at 03:06 Peter Dimov ***@***.***> wrote:
What this PR does is allow gil to be removed from
BOOST_INCOMPATIBLE_LIBRARIES here:
https://github.com/boostorg/cmake/blob/4dfbec1d500598629d56e7f6b9057ec6d1115a11/include/BoostRoot.cmake#L22-L25
which would allow it to at least be installed using CMake. It also allows
its header-only use in cases the io extensions aren't needed.
Doing this "properly" will be more involved. It will be easier, and more
"regular", if gil_io is made a normal compiled library, instead of a
header-only one, similar to Iostreams. This would allow it (at least in the
shared lib case) to be used without needing libjpeg-devel et al.
The CMakeLists file of Boost.Iostreams is a good reference example for a
similar library:
https://github.com/boostorg/iostreams/blob/9edd46fe730e2086675a91629287224bd92590ab/CMakeLists.txt
But in either case, the general outline of boostdep --cmake gil needs to
be followed, because any deviations are usually wrong, in various creative
ways. For instance, isolating dependencies or compile options in INTERFACE
subtargets, as currently done, breaks installation because these subtargets
then need to be installed.
At the moment, what I have as documentation is here:
https://github.com/boostorg/cmake/blob/doc/developer/developer.md. It's
still on a branch because it's not yet finished, but the parts that are
there, are accurate. I hope it's of help.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#614 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADGZGQC3AG3HJICON3VF3ZLUCT5PBANCNFSM46DHYUGQ>
.
|
@pdimov I read through the documents and peeked at sketches of cmake infrastructure. I do not think it is possible to make IO compiled library as they are mostly templated. What do you think about this: I will duplicate the Boost.IOStreams options function ( in the CMakeLists.txt the file you linked) and if the library is not found, there will be a preprocessor directive akin to the following (this example is for JPEG include files):
Each IO extension header will contain the preprocessor directives and if dependency was not found, any inclusion will cause a warning. I'm not sure if it is worth escalating the What Peter wanted was probably to make unusable headers unavailable, but due to nested structure and templates I do not think it is possible. In case of IOStreams it seems like there a common interface and the libraries are just backends (I guess they use virtual functions just like the standard streams), while in case of GIL it seems like at least major refactoring is needed in order to separate them (theoretically it should be possible to separate, but I do not have enough knowledge of the code base to say for sure). Anyway, I do not think any immediate action will achieve anything useful. If nobody else has anything to add, I guess we could merge this as is for now. |
Or you can just do nothing and let the user deal with linking to the library; the preprocessor warning isn't particularly useful anyway. |
I'm going to merge this into develop and, likely, cherry pick to master. If this breaks thr old way of CMake for GIL, I'll fix it later. |
No description provided.