FIFE forums

Please login or register.

Login with username, password and session length
Advanced search  

News:

FIFE 0.4.0 has been released on 15th of January, 2017!

Author Topic: proposed changes for external dependency build  (Read 2034 times)

vtchill

  • Developer
  • Full Member
  • *
  • Posts: 206
    • View Profile
proposed changes for external dependency build
« on: December 21, 2009, 03:08:59 pm »

The fife team is currently working on revamping the build system to add more features and support more targets. We are looking into the external dependency building process on linux and are trying to make this as painless as possible until we can completely remove the need for the ext/ directory.

In the build rework branch on linux we currently build local versions of guichan and png libraries as shared objects and then have to insert an rpath command into the fife shared object to link correctly to these locally build libraries. This is not an ideal solution because it hard codes the path at compile time and it is generally looked down upon by those who review packages for linux distribution repositories. In the ideal situation we would not have to rely on locally built copies of these libraries and we are working on removing the need for this, but for now we need them for various reasons (a bug in guichan, and a problem with setjmp and png).

some information on rpath can be found here: http://www.eyrie.org/~eagle/notes/rpath.html

For the short term we can think of 3 options:

(1) continue the build process as we always have and use the rpath to hard code the path in the fife shared object
(2) build the libraries as shared objects and install them somewhere on the users path (such as /usr/lib)
(3) build the libraries in ext/ as static libraries and link with fife statically so the fife executable would contain these directly preventing the need for rpath.

option 1 is the current method that the build system uses but has problems as stated above

option 2 is not ideal because we do not want to overwrite any previously installed versions of the software or have them overwrite it at a later date

option 3 I can't think of many downsides to this approach except for the fact that the size of the fife executable will increase.


If you have any opinions or would like to suggest another approach please reply. Also please indicate which option you think makes the most sense. It would be helpful to hear from current fife clients on this matter.
Logged