On 2/25/10 6:19 PM, David Lowe wrote: > On 25 Feb, 2010, at 12:20 PM, Alexander Hansen wrote: > >> On 2/25/10 2:38 PM, David Lowe wrote: >>> Greetings, >>> >>> FreeCiv 2.2.0 did build successfully on my system. This is still >>> a work in progress [DescUsage at least is outdated, and i think >>> the dependencies should be freshened], so i won't burden the list >>> with my info file yet. However, i will be glad to share it with >>> anybody who wants to see it in the meanwhile. >>> >>> The package file as currently written only configures the client >>> for the Gtk+ GUI. There is an optional SDL interface, and i >>> would like to also experiment with that. How should i handle >>> that in the context of the info file: is the preferred method to >>> make separate files like 'freeciv-gtk' and 'freeciv-sdl'? I ask >>> this question now as i think the answer to this dictates the >>> dependencies i will be looking into. >>> >>> <snip> >> >> Interesting. The existing freeciv uses both sdl and gtk+2. Does >> it not build the SDL interface? If that's the case, then I'd >> recommend leaving "freeciv" as the name of the GTK-interfaced >> package, and "freeciv-sdl" as the name of the SDL-interfaced one, >> in the interest of an easy upgrade path. > > Well, i'm inexperienced enough to not be totally sure whereof i > speak, but i don't believe the 2.0.5 package actually uses SDL at > all. In fact, the second ConfigureParam disables any configuration > of the SDL portion, so no SDL client gets built. I speculate that > the various SDL dependencies are not actually needed, and are merely > leftovers from a previous attempt to build such a client. The SDL > client is not yet as fully developed as the GTK client, and was > problematic in earlier versions. > >> How to structure the packaging is up to you. You may find it >> easier to do them as separate Variants within a single .info file, >> particularly if the build stuff for the GTK and SDL versions come >> out to be mostly the same. > > My thinking was that A) most users will only need one or the other > client; and B) separating them will reduce the dependency burden upon > the user. In my eye, the 34 dependencies as given are excessive - my > reading of the install text in the tarball shows only 10 of these as > being truly needed for a GTK build. Possibly some of them were > needed in the 1.x versions, and weren't pruned out for the 2.0 > update. Obviously i need to tread carefully here, as i'm not totally > familiar with handling dependencies. Anyway, i'm currently leaning > towards having 'freeciv' with a 'freeciv-sdl' splitoff. However, i'm > still open to input at this point. Could you please name an existing > info file that could serve as a good model for using Variants?
You don't want a freeciv-sdl splitoff. Splitoffs are for different parts of the same master package (and when built, ALL splitoffs are built together, so all Dependencies are pulled in). Using variants is just a way to have two very similar packages that use very similar build rules be maintained through the same .info file to minimize the work that the maintainer needs to do (which is what is happening here). When variant A is built, variant B is not (though it can be if there are no conflicts between the two), so Dependencies for each one are kept separate. Look at valknut.info for a quick primer on Fink variants. That's a package I have that can be built using either qt4-mac or qt4-x11. In your case, you'd have freeciv and freeciv-sdl, probably replacing -qttoolkit (for Qt toolkit type) with -client (or whatever term you want to use to describe the toolkit choice. If you go with the freeciv/freeciv-sdl naming, replace the (-aqua -x11) in the Type: field with (. -sdl). "." will give you a package called 'freeciv' and "-sdl" will give you a packge called freeciv-sdl. You can then pick and choose which Dependencies are needed for each variant (or for both). --disable-sdltest doesn't disable using SDL. It only disables the ./configure test for SDL which normally needs to be actually logged in at the OS X desktop and fails if, for example, building the package happens in an SSH session. Hanspeter ps. if the sdl version never works out, you can just simplify the above (. -sdl) line to (.) and then have just one variant. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
