On Mon, Dec 15, 2008 at 1:13 PM, Helio Chissini de Castro <[email protected]> wrote:
> On Monday 15 December 2008 09:09:29 Adam Davison wrote:
> Hello all
> I'm all against hard dependencies, from a distro point of view.
Oops, I think I got the wrong term here, my bad :)
By hard dependencies, I meant that optional header-lib requirements,
like python libs in scripting become "REQUIRED" in cmake terminology.
As in doing
(hard dependency on option WITH_SCRIPTING)
if (WITH_SCRIPTING)
find_package(PythonLibs REQUIRED)
endif(WITH_SCRIPTING)
instead of doing
(soft dependency on whether python libraries are installed)
find_package(PythonLibs)
if (PythonLibs_FOUND)
set(WITH_SCRIPTING ON)
endif (PythonLibs_FOUND)
I was not meaning to hard-code library versions in the cmake tree,
only to make enabled options an explicit configure time option.
> Imagine that to assure adoption of mixxx in all distributions + windows + OSX,
> you will need to say that all systems should have your stated versions of the
> package.
Well, the good thing is that we can do Windows and OSX packaging ourselves
cpack makes this a matter of minutes. The current cmake patch
automatically finds mixxx-osxlib and mixxx-winlib so one only has to
download those to build on a clean system.
This leaves us with linux-bsd-other systems with proper packaging. The
current patch will accept any library version it finds (I think the
only version tests are for ffmpeg) and will dynamically link against
that version. However, I have not tested this completely so it might
be that your Find checks behave better in that sense.
> - The worst: Distro will not ship package at all. And of course, as we are
> open source and is all about freedom, this always lead to some non official
> package made from someone that want mixxx for their distro, but is not direct
> related for the distro work. And even doing for personal use, sometimes this
> packages fall in the public and more people will be using.
I agree, not having distro support is a no-go and unofficial packages
can be a pain. So if there are other package maintainers reading, I'd
like to hear your voice on this. How can I reduce the amount of
patching you need to do on upstream?
(Not shipping a default debian directory is a start, but we can handle
that later ;) )
> The only way that we can prevent this scenarios would be using old method of
> add all depends sources inside mixxx source download, and believe me, this is
> not pretty.
+1
> So my 2c is do that:
> Soft dependencies, but with minimal test range, like, we know that libfoo
> works from version >= 0.9, then we force the test to do exactly that. If a new
> incompatible version appears, distro will report quickly and we can receive
> quick status. If distro have an older version, than packager will be ready to
> pick any version after 0.9 that suits better their system.
+1 on this too
--
Claudio Bantaloukas http://www.rdfm.org/ammuzzu/
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Mixxx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
