FreeCAD build, need cmake help

[Richard Shaw]

On Mon, Nov 28, 2011 at 2:43 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Richard Shaw wrote:
>> On Mon, Nov 28, 2011 at 2:09 PM, Kevin Kofler wrote:
>>> That looks like it'll work, though I'd actually change the INSTALL
>>> commands to use the standard CMake macros for the destination and then
>>> change the "portable" case to override the values of those macros, rather
>>> than having the systemwide case be the special case (because the
>>> systemwide case is really the normal one :-) ).
>>
>> Let me know what you mean by "standard" cmake macros just so I'm sure
>> I know what you're talking about.
>
> The ones our %cmake macro sets, which are the ones used by most CMake-using
> projects.
>
> (That said, unfortunately, there is no one standard, which is why our macro
> has to set all 3 of CMAKE_INSTALL_LIBDIR, LIB_INSTALL_DIR and, on x86_64,
> LIB_SUFFIX. I think LIB_INSTALL_DIR is actually more commonly used than
> CMAKE_INSTALL_LIBDIR and should thus be preferred.)
>
>> By default you can use relative paths for DESTINATION which are relative
>> to CMAKE_BINARY_DIR, right?
>
> Aren't they relative to CMAKE_INSTALL_PREFIX, actually?

Probably :) I got a lot of cmake macros floating around in my head ATM...


>> In that case all the absolute paths I'm setting are more or less
>> useless...
>
> To be honest, I've found relative paths to cause more problems than they
> solve here, because then if you mix the relative paths with absolute ones,
> they can cause trouble. E.g. I've seen some upstream projects write
> something like ${CMAKE_INSTALL_PREFIX}/${LIB_INSTALL_DIR} into their .pc
> files, which then breaks badly when %cmake sets LIB_INSTALL_DIR to an
> absolute path (and we have to patch some upstream CMakeLists.txt files
> because of this issue).

Make sense.


>> I may also add an option, something like NO_BUNDLED_APPS and default
>> to OFF. That way I can stop using bundled libs without patches. Or add
>> individual options for each bundled app... I'll still "rm -rf" them in
>> %prep though.
>
> That makes a lot of sense, but it should probably be called NO_BUNDLED_LIBS
> or NO_BUNDLED_LIBRARIES instead. Or maybe BUNDLED_LIBRARIES or
> USE_BUNDLED_LIBRARIES which can be set to OFF.

That's what I wanted to use, but I've noticed that sometimes apps are
bundled as well as libraries. The one case I can think of on top of my
head is OpenColorIO, which uses some bundled apps to generate their
documentation. I guess since they aren't installed it's not as big of
a problem I just went for a more generic name.

Thanks,
Richard