[CMake] Anyone gotten OpenSSL to build as an external project?

[David Cole]

On Fri, Jan 14, 2011 at 3:43 PM, Pau Garcia i Quiles
<pgquiles at elpauer.org>wrote:

> Hi,
>
> I'm trying to get this working on Windows using a self-contained build
> environment that does NOT have Perl in path.
>
> It's a .bat file which downloads CMake and Perl and then fires a
> CMakeLists.txt with the ExternalProject_Add to build zlib (no problem
> after the patches I sent yesterday) and OpenSSL.
>
> One problem I've found is the PATH environment variable.
> ExternalProject_Add does not allow to set it, which forces me to use
> CMake in command mode + set (ENV{PATH} ... ) + execute_process. Ugly.
>
> Features I'm missing in ExternalProject_Add and I just realized
> "thanks" to OpenSSL:
> - Add a PATH parameter to ExternalProject_Add,
> ExternalProject_Add_Step and execute_process. It should override the
> default path. Adding new directories to the path would be possible by
> doing PATH "$ENV{PATH}:/my/new/dir/in/path"
>

Good suggestion. Actually, we've wanted to add a feature to specify
environment variables to arbitrary calls to add_custom_command for quite a
while, but there are some subtle details behind it, and we haven't found the
time and funding to get that done yet. This would be an easy pass-through
from ExternalProject to such a feature as soon as the underlying feature
exists in add_custom_command.



> - Define variables for SOURCE_DIR, BINARY_DIR, etc even if EP_PREFIX
> and EP_BASE are not set
>

Not sure what you mean here?

If you got a ExternalProject_Get_Property(${proj} source_dir) immediately
after an ExternalProject_Add call you can retrieve the value of its source
dir regardless of if you have EP_PREFIX or EP_BASE set, right? Those only
control some of the default layouts that we had come up with when trying to
organize things.


- Allow for multiple CONFIGURE_COMMAND steps (I know, I can add my
> custom step, but it's much more complex)
>

How many would you like? Why not just run a script as the single configure
command, and then have your script do the multiple steps needed?



> Another more issue I'm seeing with ExternalProject_Add is tarballs
> with symlinks on Windows. The OpenSSL contains symlinks, which leads
> to a broken source dir because CMake is unable to create some files.
> Maybe CMake should pass libarchive some parameter? (if I extract the
> OpenSSL tarball with WinRAR, it does not fail)
>

What does WinRAR give you? Symlinks because the Windows you're using
supports them? Or copies of the linked-to files in place of symlinks? Or
something else?



>
> On Fri, Jan 7, 2011 at 9:34 PM, kent williams <nkwmailinglists at gmail.com>
> wrote:
> > This shouldn't be a big deal -- something like this should work:
> >
> > ExternalProject_add(OpenSSL
> >    URL "http://www.openssl.org/source/openssl-1.0.0c.tar.gz"
> >    URL_MD5 ff8fb85610aef328315a9decbb2712e4
> >    CONFIGURE_COMMAND ./config
> --prefix="${CMAKE_CURRENT_BINARY_DIR}/OpenSSL"
> >   BUILD_IN_SOURCE 1
> >     INSTALL_DIR "${CMAKE_CURRENT_BINARY_DIR}/OpenSSL"
> >   )
> > set(OPENSSL_INCLUDE_DIR "${CMAKE_CURRENT_BINARY_DIR}/OpenSSL/include")
> > link_directories("${CMAKE_CURRENT_BINARY_DIR}/OpenSSL/libs)
> > set(OPENSSL_LIBRARIES ssl ssleay32 ssleay32MD)
> >
> > The problem is that OpenSSL doesn't handle configuration scripts in
> > the usual way -- the configure script wants you to specify your
> > platform/compiler string.
> >
> > They provide an 'automatic' script instead called config, so
> >
> > config --prefix=...
> >
> > Does mostly what you want, but they make you handle the OS X 64-bit
> > case manually -- it wants you to run configure and tell it explicitly
> > about the platform:
> >
> > ./Configure darwin64-x86_64-cc
> >
> > This is kind of crazy, but OK, whatever. So I need to try and figure
> > out at configure time if it's an OS X build and if it's a 64 bit
> > build.  I can use
> >
> > if(APPLE)
> >
> > to detect an Mac platform, but there's no way I can figure out to
> > determine if the currently selected build type is 64 bits.  And I
> > think that the stock OpenSSL distribution would completely lose its
> > mind if you tried to configure a Universal Binary build!
> >
> > Any suggestions?
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Follow this link to subscribe/unsubscribe:
> > http://www.cmake.org/mailman/listinfo/cmake
> >
>
>
>
> --
> Pau Garcia i Quiles
> http://www.elpauer.org
> (Due to my workload, I may need 10 days to answer)
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110114/0e187c43/attachment.htm>