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

Pau Garcia i Quiles pgquiles at elpauer.org
Fri Jan 14 17:55:38 EST 2011


On Fri, Jan 14, 2011 at 11:32 PM, David Cole <david.cole at kitware.com> wrote:
> 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.

Great

> (Sorry, I
> know this is a lame cop-out, but it's Friday afternoon...)

:-)

>> 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."

Oh, cool. I thought those were only placeholders in the documentation.
It works exactly as I wanted!

>> >> - 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.

What do you mean by "readable"? Not having read the implementation of
ExternalProject_add, implementation looks easy, something like

while( nextstr == "CONFIGURE_COMMAND" ) {
...
}

>> >> 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.

The libarchive docs show how to extract symlinks, hardlinks, etc

http://code.google.com/p/libarchive/wiki/Examples

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)


More information about the CMake mailing list