This is an archive of the discontinued LLVM Phabricator instance.

[CMake] use findzlib util to include zlib
AbandonedPublic

Authored by Holman on Nov 20 2019, 4:57 PM.

Details

Reviewers
rnk
labath
beanz
Summary

See PR19403:
https://bugs.llvm.org/show_bug.cgi?id=19403

This change makes it much easier to use zlib when it isn't on the system include path (e.g. on Windows).
Instead of modifying compiler and linker flags, the user just has to set the CMAKE variable ZLIB_ROOT or ZLIB_INCLUDE_DIRS/ZLIB_LIBRARIES.

Diff Detail

Event Timeline

Holman created this revision.Nov 20 2019, 4:57 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 20 2019, 4:57 PM

With this patch, what is the output of llvm-config --system-libs ? I remember that as being the main reason for why this code is written the way it is... If it stays as -lz then I think this should be fine (and better than the previous version).

Ah thanks for the context! Unfortunately, it does change that to -l/usr/lib/x86_64-linux-gnu/libz.so. What do you think if I call FindZLIB if (ZLIB_ROOT OR ZLIB_INCLUDE_DIR OR ZLIB_LIBRARY), and otherwise use the existing loop?

Holman updated this revision to Diff 230558.Nov 21 2019, 4:14 PM

Only use FindZLIB if one of the relevant variables is set.

labath added a subscriber: beanz.

Ah thanks for the context! Unfortunately, it does change that to -l/usr/lib/x86_64-linux-gnu/libz.so. What do you think if I call FindZLIB if (ZLIB_ROOT OR ZLIB_INCLUDE_DIR OR ZLIB_LIBRARY), and otherwise use the existing loop?

I think that's... suboptimal? Let me pull in @beanz here as he has a lot of ideas about cmake (though some of his ideas include deleting llvm-config :P).

Overall, I very much like using standard cmake solution for finding dependencies, but don't like duplicating logic even more. Maybe we could pry apart (either in cmake or llvm-config) that /usr/lib/x86_64-linux-gnu/libz.so into appropriate -L -l switches? Or just get llvm-config to drop the -l from -l/usr/lib/x86_64-linux-gnu/libz.so, so it produces a valid (though not completely equivalent) compile line?

hans added a subscriber: hans.Feb 3 2020, 5:24 AM

Looks like a different version of this landed in abb00753069554c538f3d850897373d093389945 ?

Holman abandoned this revision.Feb 3 2020, 10:41 AM

Yup, it looks like that supersedes this change. Closing this one out.