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

[David Cole]

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

> On Fri, Jan 14, 2011 at 9:52 PM, David Cole <david.cole at kitware.com>
> wrote:
> >> - 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.
>
> What are those subtle details?
>
>
I don't have them written down... every time Brad and I discuss this topic,
though, we go down the rabbit hole and find them again. Next time, I'll try
to write them down somewhere so that I can answer this succinctly. (Sorry, I
know this is a lame cop-out, but it's Friday afternoon...)



> >> - 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.
>
> For OpenSSL, I need to know ExternalProject_Get_Property(${proj}
> source_dir) *while* I am still in ExternalProject_Add. This is still
> work in progress but here is what I am doing now:
>
> ExternalProject_Add( openssl
>    DEPENDS zlib
>    DOWNLOAD_DIR ${PROJECT_SOURCE_DIR}/downloads
>    URL http://openssl.org/source/openssl-1.0.0c.tar.gz
>    PATCH_COMMAND ${PROJECT_SOURCE_DIR}/bin/patch.exe -p1 <
> ${PROJECT_SOURCE_DIR}/downloads/openssl-1.0.0c.patch
>    CONFIGURE_COMMAND ""
>    BUILD_COMMAND ${CMAKE_COMMAND} -DWINST_DIR=${PROJECT_SOURCE_DIR}
> -DOPENSSL_SOURCE_DIR=${PROJECT_BINARY_DIR}/openssl-prefix/src/openssl/
> -DOPENSSL_GENASM_COMMAND=${OPENSSL_GENASM_COMMAND}
> -DOPENSSL_CONFIGURE_COMMAND=${OPENSSL_CONFIGURE_COMMAND}
> -DOPENSSL_BUILD_COMMAND=${OPENSSL_BUILD_COMMAND}
> -DOPENSSL_INSTALL_COMMAND="${OPENSSL_BUILD_COMMAND} install" -P
> ${PROJECT_SOURCE_DIR}/configure-openssl.cmake
>    BUILD_IN_SOURCE 1
>    )
>
> Where configure-openssl.cmake is generates the assembly code, runs
> perl Configure, nmake and nmake install. The relevant part here is
>
> -DOPENSSL_SOURCE_DIR=${PROJECT_BINARY_DIR}/openssl-prefix/src/openssl/
>
> in BUILD_COMMAND. OpenSSL must be built in-tree, which means you need
> to know where the source tree is while in the ExternalProject_Add
> call.
>
>
So... just use <SOURCE_DIR> as part of a command, and it should substitute
it for you... See
http://cmake.org/cmake/help/cmake-2-8-docs.html#module:ExternalProject --
specifically this section:

"The command line, comment, and working directory of every standard and
custom step is processed to replace tokens <SOURCE_DIR>, <BINARY_DIR>,
<INSTALL_DIR>, and <TMP_DIR> with corresponding property values."



> >> - 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?
>
> That's what I'm currently doing, which is why I have the problem
> above: I need to know the source directory, the build directory, etc
> of that ExternalProject. That means you need to pass variables, set
> PATH, etc. It'd be easier if an arbitrary number of CONFIGURE_COMMAND
> would be run in order before the BUILD_COMMAND.
>
>
I'll think about it, but it's hard to see how an abitrary number of steps
(that are not simply custom defined steps with their own names) would be
readable in the ExternalProject_Add interface. It's very useful, but it's
already, at its young age, quite crowded with parameters.

... <Planting reminder seed deep into brain tissue. Water, nourish, and
check back later.> ...



> >> 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?
>
> Copies of the linked-to files in place of symlinks.
>

Thanks for the info.



>
> --
> Pau Garcia i Quiles
> http://www.elpauer.org
> (Due to my workload, I may need 10 days to answer)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110114/fcc46ebd/attachment-0001.htm>