Platform specific build hints

[tmetro]

I found on Ubuntu 9.04 that I needed to specify a path (".") after cmake, even when ran from the project directory.

You may want to include hints for building on a few platforms, and for Ubuntu, that would be something like:

sudo aptitude install cmake
sudo apt-get build-dep pidgin
sudo aptitude install libpurple-dev

This probably needs refinement, as I don't understand why "build-dep pidgin" didn't include libpurple-dev. And if it doesn't, it may be a useless step.

[costela]

Well, this is a little off-topic here, but as a DD I guess I should answer: "build-dep pidgin" doesn't install libpurple-dev because the "build-dep" action means "install everything that pidgin needs to build". Since libpurple-dev is built together with the package pidgin (that means: they come from the same source package), it would be a chicken-and-egg problem when trying to build it for the first time.

It's good that you mention the need for a path when building in-source. I never use cmake in-source, so I had totally forgotten about that. Will add it to the INSTALL file.

As for the needed libraries, I think the build system is already explicit enough about it, but a short "you need A, B and C" notice could be helpful.
I don't feel it's the right place in an INSTALL file to explain how to get the needed libraries in any specific distro, though. It's just too generic and would easily become outdated and inaccurate.

Cheers

[tmetro]

...libpurple-dev is built together with the package pidgin...

Ah, of course. That makes sense.

I don't feel it's the right place in an INSTALL file to explain how to
get the needed libraries in any specific distro...

If the trend is towards providing distro-specific packages (many "upstream" OSS projects now directly provide debs, for example), then providing distro-specific build hints is a reasonable middle ground for a project that doesn't want to maintain packages.

(I see there are some tools now for automating package builds for multiple distros and architectures.)

...would easily become outdated and inaccurate.

The remedy there is to link to a wiki page and let your users keep the info current.

[costela]

Replying to tmetro:

If the trend is towards providing distro-specific packages (many "upstream" OSS projects now directly provide debs, for example), then providing distro-specific build hints is a reasonable middle ground for a project that doesn't want to maintain packages.

Speaking not only with my Debian Developer hat on, but as upstream as well, to a minor extent:
I don't see it as a trend and even if it is, it's IMHO not a very helpful one, in most cases. The only situations I see it helping is when the project is evolving too fast to wait for distros to catch up and where the bleeding-edge matters more than the integration. Otherwise we'd slowly drift to a situation where the big advantage of distros (namely the attempted smooth integration of many not necessarily conjoined parts) fades away, and we're left with a Windows-esque scenario of having to download packages from different sources and with different levels of quality, none of them really interested in the big picture of having a system with potentially tens of thousands of pieces of software interacting.
But this is going a bit besides the point. In summary: I'm a big supporter of the distro way of looking at it and still don't think it's a good idea to include distro-specific notes in the INSTALL file. If the user doesn't have enough knowledge to infer which packages are needed to build from the build-system messages (which admittedly should be explicit enough), he shouldn't be building it manually in the first place (at the risk of polluting his system) and should instead either use the distro package or poke the chosen distro into creating the package, if it doesn't yet exist.

That being said, I'd still be open for distro-specific stuff if it were some big gotcha, instead of just the bread-and-butter of compilation.

...would easily become outdated and inaccurate.

The remedy there is to link to a wiki page and let your users keep the info current.

True, but I don't really think a wiki for such a small project would be worth the hassle (keeping it free from spam, etc). Judging by the real to bogus user ratio in the Trac, it would be hard to keep it clean. That's why I disabled trac's wiki in the first place.