Displaying 3 results from an estimated 3 matches for "zlib_include_dir".
Did you mean:
zlib_include_dirs
2016 Sep 01
2
change in CMake variable names breaks existing uses and does not conform to CMake conventions
...s rename is desirable at all. Sure, in-tree LLVM_INCLUDE_DIR is used everywhere, however not providing an ${NAME}_INCLUDE_DIRS variable goes against CMake conventions. See for example the find scripts included with CMake itself:
https://cmake.org/cmake/help/v3.6/module/FindZLIB.html -> provides ZLIB_INCLUDE_DIRS (and not ZLIB_INCLUDE_DIR) even though it is typically only one directory
And the same holds true for most other Find${NAME}.cmake scripts I had a look at (Boost, Bullet, CUDA, Freetype, XMLRPC, Zlib). I'll admit there are 1 or 2 exceptions (such as OpenGL) but in general I think it would be...
2014 Sep 17
2
[LLVMdev] proposal to avoid zlib dependency.
On 17 September 2014 15:47, Mueller-Roemer, Johannes Sebastian
<Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote:
> It's half the way there. Configuring and compiling works, but linking fails, probably some definition mismatches...
It configured, compiled and linked okay for me. Could you look into it?
>
> But it can definitely be simplified, as due to the
2014 Sep 17
2
[LLVMdev] proposal to avoid zlib dependency.
On 17 September 2014 16:34, Mueller-Roemer, Johannes Sebastian
<Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote:
> I'll have another look tomorrow.
Thanks.
> IMO, it is unnecessary clutter. It will fail if ${ZLIB_LIBRARIES} or ${ZLIB_INCLUDE_DIRS} are used anyways as they will be set to NOTFOUND. Or we go back to a silent-fail solution:
Fair enough. I've never been a big fan of silent failure. So perhaps
just this...
```
if (LLVM_ENABLE_ZLIB )
find_package(ZLIB REQUIRED)
set(HAVE_ZLIB_H 1)
set(HAVE_LIBZ 1)
list(APPEND C...