vszakats wrote:
> Well, if your aim is to include linuxdcpp as a MacPorts port, which is a reasonable 
> goal, you should naturally deal with some extra problems, but currently linuxdcpp 
> isn't available as standard port

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.

>> Could be that some ports have special requirements, but please don't form the general idea around a few exceptions.
>> This is the *rule*, not the exception. In any source-based packaging system, packages have a "build-depends" list of 
>> packages from the same packaging system, that are required to build the package. The build is done using the packaging 
>> system's own toolchain. Eg. dpkg-buildpackage for debian, port for MP.
> 
> IMO you're confusing the packaging system with the compiler toolchain.

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.

> The whole point of MacPorts is to provide binary packages (tools or libs) 
> to be used by OS X apps. For libs you'll of course need to make sure ABI / 
> CPU arch are matching (You DON'T have to use the exact same GCC 
> build or version, though!). From this point it's safe to use MacPorts libs 
> from non-MacPorts apps. And this takes us back to the original point:

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.

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 chose 1) because it's the more natural and simple. This is what's covered 
> in the instructions. (which BTW, you're not obliged to use, I've sent it in my 
> free time, just to add some minor help to this project)

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.

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.