7:27 p.m.
I did some searching and found an old thread about building FreeCAD
0.7 for Fedora 10 with autotools.
The good news is that FreeCAD now has a cmake option as well. The bad
news is that they didn't think it through very well for system wide
installs, meaning, it doesn't handle them period. It expect everything
to be installed under $HOME and be a stand alone app.
They are receptive to improvements for fixing the cmake build[1] as
they currently use a hackish script to make the build work system wide
for Debian. Though I'm not sure my cmake skills are up to the task.
In order to not change expectations for current builders I added a
cmake option FREECAD_PORTABLE_INSTALL and defaulted it to ON.
I've started hashing out the logic to set all the required paths
correctly using the names from the rpm %cmake macro. I think I can
make it work but this is where some best practices examples would be
really helpful.
I don't want to post the whole CMakeLists.txt file but here's the
chunk I added so far:
OPTION(FREECAD_PORTABLE_INSTALL "Build for use as a portable install
(Default)." ON)
# ============================================================
# == Check for and set required definitions for system wide install ==
# ============================================================
IF(UNIX AND NOT FREECAD_PORTABLE_INSTALL)
MESSAGE(STATUS "Setting up system wide install.")
# Make sure install prefix is set.
IF(NOT CMAKE_INSTALL_PREFIX)
MESSAGE(FATAL_ERROR "For system installs CMAKE_INSTALL_PREFIX
must be specified.")
ENDIF(NOT CMAKE_INSTALL_PREFIX)
# Set library install dir if not already specified.
SET(LIB_INSTALL_DIR ${CMAKE_INSTALL_LIBDIR})
IF(NOT LIB_INSTALL_DIR)
SET(LIB_INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/lib${LIB_SUFFIX})
ENDIF(NOT LIB_INSTALL_DIR)
MESSAGE(STATUS " LIB_INSTALL_DIR: ${LIB_INSTALL_DIR}")
# Set data dir if not already specified.
IF(SHARE_INSTALL_PREFIX AND NOT SHARE_INSTALL_DIR)
SET(SHARE_INSTALL_DIR ${SHARE_INSTALL_PREFIX}/freecad)
ELSEIF(NOT SHARE_INSTALL_PREFIX AND NOT SHARE_INSTALL_DIR)
SET(SHARE_INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/share/freecad)
ENDIF(SHARE_INSTALL_PREFIX AND NOT SHARE_INSTALL_DIR)
MESSAGE(STATUS " SHARE_INSTALL_DIR: ${SHARE_INSTALL_DIR}")
# Set include directory if not already specified.
IF(NOT INCLUDE_INSTALL_DIR)
SET(INCLUDE_INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/include/freecad)
ENDIF(NOT INCLUDE_INSTALL_DIR)
MESSAGE(STATUS " INCLUDE_INSTALL_DIR: ${INCLUDE_INSTALL_DIR}")
ELSEIF(NOT UNIX AND NOT FREECAD_PORTABLE_INSTALL)
MESSAGE(FATAL_ERROR "System wide installs are currently only
supported on *nix based systems.")
ELSE(UNIX AND NOT FREECAD_PORTABLE_INSTALL)
MESSAGE(STATUS "Installation will be portable.")
ENDIF(UNIX AND NOT FREECAD_PORTABLE_INSTALL)
--- EOF ---
Suggestions before I get to far down this road?
Thanks,
Richard
[1] http://tinyurl.com/bos58oc (forum thread)
8:09 p.m.
Richard Shaw wrote:
Suggestions before I get to far down this road?
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 :-) ).
Kevin Kofler
8:21 p.m.
On Mon, Nov 28, 2011 at 2:09 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Richard Shaw wrote:
> Suggestions before I get to far down this road?
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. By default you can use relative
paths for DESTINATION which are relative to CMAKE_BINARY_DIR, right?
In that case all the absolute paths I'm setting are more or less useless...
As far as the name and default, I thought about it and already changed
the option name to FREECAD_SYSTEM_INSTALL defaulted to OFF. I'll ask
if it can be defaulted to ON but as long as I have a switch to flip,
I'm happy.
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.
Thanks,
Richard
8:43 p.m.
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?
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).
As far as the name and default, I thought about it and already
changed
the option name to FREECAD_SYSTEM_INSTALL defaulted to OFF. I'll ask
if it can be defaulted to ON but as long as I have a switch to flip,
I'm happy.
OK.
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.
Kevin Kofler
8:49 p.m.
On Mon, Nov 28, 2011 at 2:43 PM, Kevin Kofler <kevin.kofler(a)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
5:13 p.m.
Ok, next question.
I've updated all the install targets to the proper location but I'm
not sure that's enough. There's a lot of "set_target_properties"
entries like the one below. Do I need to modify these or are they just
for the build tree?
set_target_properties(FreeCADApp PROPERTIES
LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
Thanks,
Richard
2:18 a.m.
Additionally,
I've finally got it building and got all the RPATH's set for the
private libraries.
I'm actually getting a functional window when running the gui! (yay
for small victories)
But it's still looking for it's plugins modules in /usr/Mod instead of
/usr/lib64/freecad/Mod.
Does this have anything to do with LIBRARY_OUTPUT_DIRECTORY or
RUNTIME_OUTPUT_DIRECTORY?
Or is this getting set somewhere else?
Thanks,
Richard
5:17 p.m.
Richard Shaw wrote:
But it's still looking for it's plugins modules in /usr/Mod
instead of
/usr/lib64/freecad/Mod.
Does this have anything to do with LIBRARY_OUTPUT_DIRECTORY or
RUNTIME_OUTPUT_DIRECTORY?
Or is this getting set somewhere else?
This is probably hardcoded somewhere in the code, probably through some -D
flag being passed to the compiler by the build system. Look for
add_definitions calls in the CMakeLists.txt files.
Kevin Kofler
7:11 p.m.
On Wed, Nov 30, 2011 at 11:17 AM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Richard Shaw wrote:
> But it's still looking for it's plugins modules in /usr/Mod instead of
> /usr/lib64/freecad/Mod.
>
> Does this have anything to do with LIBRARY_OUTPUT_DIRECTORY or
> RUNTIME_OUTPUT_DIRECTORY?
>
> Or is this getting set somewhere else?
This is probably hardcoded somewhere in the code, probably through some -D
flag being passed to the compiler by the build system. Look for
add_definitions calls in the CMakeLists.txt files.
It turns out it's largely Python based and looks for the Mod directory
relative to the binary directory.
I talked to one of the developers and he said it would be better to go
ahead and put everything in /usr/lib{,64}/freecad and symlink the
binaries to /usr/bin. It makes my system install option pretty much
useless since you can set the install location by overriding
CMAKE_INSTALL_PREFIX, but I still have to setup the proper rpath's so
everything can find everything else...
Thanks,
Richard
8:12 p.m.
Richard Shaw wrote:
It turns out it's largely Python based and looks for the Mod
directory
relative to the binary directory.
That should probably be patched.
I talked to one of the developers and he said it would be better to
go
ahead and put everything in /usr/lib{,64}/freecad and symlink the
binaries to /usr/bin. It makes my system install option pretty much
useless since you can set the install location by overriding
CMAKE_INSTALL_PREFIX, but I still have to setup the proper rpath's so
everything can find everything else...
I'm not sure I like this solution… I think fixing the Python code to support
systemwide installations properly would be a better solution than this hack.
Though *I* won't be using that non-Free software (well, based on a non-Free
library) anyway. ;-)
Kevin Kofler
8:34 p.m.
On Thu, Dec 1, 2011 at 2:12 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Richard Shaw wrote:
> It turns out it's largely Python based and looks for the Mod directory
> relative to the binary directory.
That should probably be patched.
> I talked to one of the developers and he said it would be better to go
> ahead and put everything in /usr/lib{,64}/freecad and symlink the
> binaries to /usr/bin. It makes my system install option pretty much
> useless since you can set the install location by overriding
> CMAKE_INSTALL_PREFIX, but I still have to setup the proper rpath's so
> everything can find everything else...
I'm not sure I like this solution… I think fixing the Python code to support
systemwide installations properly would be a better solution than this hack.
Yeah, I'm not thrilled about it but I didn't get the sense that
upstream is willing to update their code for that. At least not yet,
I'll see if I can wear him down :)
Though *I* won't be using that non-Free software (well, based on
a non-Free
library) anyway. ;-)
Yup, not thrilled about that either but there isn't really an
alternative that I know of for solid modeling. If you just need 2D
architecture type work then you can just use qcad.
Richard
5:16 p.m.
Richard Shaw wrote:
I've updated all the install targets to the proper location but
I'm
not sure that's enough. There's a lot of "set_target_properties"
entries like the one below. Do I need to modify these or are they just
for the build tree?
set_target_properties(FreeCADApp PROPERTIES
LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
IIRC those are only for the build tree.
Kevin Kofler
4527
days inactive
4530
days old
rpmfusion-developers@lists.rpmfusion.org
11 comments
2 participants
participants (2)
-
Kevin Kofler -
Richard Shaw