Re: [coolfluid-dev] dependencies

[Bart Janssens]

On Fri, Jan 13, 2012 at 1:42 PM, Tiago Quintino <tlmqu...@gmail.com> wrote:
> This may be interesting to insert project dependencies into coolfluid.
> http://www.kitware.com/products/html/BuildingExternalProjectsWithCMake2.8.html

This looks very promising. Maybe one day it could replace the install_deps.pl?
On a related note, I got a message from the K-3D debian package
maintainer stating that the inclusion of existing libraries (K-3D has
some boost gil extension and the glew opengl lib) is grounds for
refusal of a package. We should keep this in mind as a warning that
including external dependencies as in our include directory should be
kept to the bare minimum, and eliminated when possible. That is
assuming we ever want to get a supported debian/RedHat/whatever
package out there, but I think we should keep that possibility open
for the future.

Cheers,

--
Bart

[Tiago Quintino]

On Fri, Jan 13, 2012 at 1:25 PM, Bart Janssens
<bart.j...@lid.kviv.be> wrote:
> On Fri, Jan 13, 2012 at 1:42 PM, Tiago Quintino <tlmqu...@gmail.com> wrote:
>> This may be interesting to insert project dependencies into coolfluid.
>> http://www.kitware.com/products/html/BuildingExternalProjectsWithCMake2.8.html
>
> This looks very promising. Maybe one day it could replace the install_deps.pl?

That was my point precisely ;)

> On a related note, I got a message from the K-3D debian package
> maintainer stating that the inclusion of existing libraries (K-3D has
> some boost gil extension and the glew opengl lib) is grounds for
> refusal of a package. We should keep this in mind as a warning that
> including external dependencies as in our include directory should be
> kept to the bare minimum, and eliminated when possible. That is
> assuming we ever want to get a supported debian/RedHat/whatever
> package out there, but I think we should keep that possibility open
> for the future.

Sure, we should keep that in mind. Eventually we will be shipping RPM/Debs no?
Anyway, I think we can always put a cmake variable to use the internal
from the /include dir or use an external one.

For example, if we define:

-DRAPID_XML_PATH=/path/to/

then we ignore the internal /include/rapidxml and we use the external
one -- which might or not work, but that is up to the package
maintainer.

Finally, there is surely a distinction between:
* header only packages (Eigen, rapidxml)
* packages that generate binaries ( fparser, qwt)

Probably only the later is really an issue for conflicts with other
deb/rpm packages.

Best,

--
Tiago Quintino