> Sorry, this is what I meant. We created our own custom MacPorts repository and
> LinuxDC++ Portfile. I realise my first post was a bit confusing now.

Okay that clears it up, BTW the first thing I checked was whether 
MacPorts hosts linuxdcpp, but couldn't find it. It would be nice 
if it would be there.

> I'm talking about the packaging toolchain, which builds packages. This sits on
> top of the compiler toolchain and automatically configures things like compiler
> flags, dependencies, etc.

> Using the compiler directly is usually not done for distribution forms of free
> software - instead, we make a packaging metafile (for MacPorts this is the
> Portfile) and call the packaging system's toolchain to build it automatically.

In this context it makes perfect sense.

> The whole point of MacPorts is "to design an easy-to-use system for compiling,
> installing, and upgrading either command-line, X11 or Aqua based open-source
> software on the Mac OS X operating system."
>
> Using MacPorts libraries to compile standalone (as in not a MacPorts package)
> software is basically a hack, and unsupported by the MacPorts team. It's like
> using libraries from a .deb package to compile a binary for a .rpm package. If
> it works, then it's only by chance that all the files happen to be in the same
> locations under both systems.

It's not really about locations IMO, since this is quite easy to solve 
in most cases. But rather the potential incompatibilities between "ports" 
and system libs.

> Maybe this isn't a problem for Mac, I don't know, but it's not a good solution
> in principle, especially if you intend to distribute the resulting binaries.

I agree there can be potential issues with distribution, but I haven't 
dealt with this part yet, so can't tell anything meaningful.

Anyhow, currently this is the only reasonable way to create OS X apps
NOT hosted by MacPorts (which may happen easily with ones app) and 
at the same time building upon the many available libs in a straightforward 
way. Simply, unlike on Linux, there'll always be a boundary between 
system hosted libs and "extras" provided by MacPorts / Fink. The other way 
is to build non-system packages directly from source, with all the pros and 
cons. (Plus, MacPorts can't really think seriously that developers will build 
solely upon MacPorts tools to build final apps.)

Still, my LinuxDC++ build works perfectly in above mixture. Maybe it's a 
hack, but it works.

> Sorry, I know you're trying to help. I suppose the instructions are fine if you
> understand what you're doing, but I was looking at them through the eyes of a
> Mac user who "just wants to run LinuxDC++" and doesn't understand the concept
> of a packaging system, and the potential problems of mixing software from two.

Well, it's an INSTALL instructions doc :) Building stuff from source obviously 
requires some level of involvement in these sorts of things. Believe me, I'd have 
also been happier if I could just simply download a .dmg file and drag&drop 
Linux DC++.app on my Desktop.

> The best solution would be for someone to maintain an official MacPorts
> package. Do you want to do it? As I said, I have a Portfile already - it'll
> need a few tweaks, but it's mostly in working condition. I don't want to do it
> myself because I don't actually own a Mac so can't test updates easily.

Thank you for the trust, but I'm afraid I just can't add it to my task list this 
time. I'm deeply into another OSS project and it pretty much takes up all my 
free time already, sorry.