linuxdcpp-team team mailing list archive

[vszakats <vszakats@xxxxxxxxxxx>]

> I reckon most users won't bother building it from source though, when there is a plain installer.
> As a MacPorts developer, you should build MP packages by making a Portfile for it, then using "port build" or whatever the 
> command is. Any other way (such as using "gcc" directly) might work, but is essentially an improper hack.

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, and all my instructions were written to cover 
current situation. In current situation direct usage of GCC is the _only_ way to 
build linuxdcpp on OS X, and I was covering exactly that.

Definitely for MacPorts ports 'install <portname>' is the way to go for users, and I'm 
not sure who (and why) would want to use hacks instead, if it's possible at all.

Anyhow someone may want to manually build packages (outside the realm of 
MacPorts or other port engines), which is also perfectly valid, and may even work, 
and in this case using GCC compiler directly is the way to go. (exactly like with 
linuxdcpp)

> 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.

Just to repeat: My system, which is a fairly default one, has NO MacPorts 
GCC installed, only XCode supplied GCC, and installation (build) of any 
MacPorts ports is possible.

> You may even build packages which are already present in base OS install
> You should realise that this is "the smoking gun". MP needs its own version of the packages for its own build system, 
> because it is a *self-contained packaging system*, like dpkg/apt. For example, in any debian system you can use gcc to 
> compile a program, but this is not the "proper way" of creating a software package for debian (this is analogous to what you > seem to be doing - installing MacPorts libraries then using gcc to compile another non-MacPorts software). Anyone who 
> wants to do this should realise that they might need to add some extra flags or hacks for the compile to work.

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:

At this moment, for linuxdcpp to be built on OS X, you must use MacPorts 
ports (maybe other porting efforts could also work, but we stick with MacPorts now).

Here there seems to be a user choice to use compiler toolchain:
1) GCC from XCode
2) GCC from MacPorts
+1) probably even a mixture would also work.

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)

If you stick with 1), you will have to use an extra setting to point to a certain 
package, because probably due to some scons bug (or feature, or port bug, 
reason out of scope of this post) this is not getting detected (while the others are).

If you use 2), /opt/local/include may be added automatically at some stages 
of the build process, so this extra setting may not be needed. I didn't try this one.

You can document both to make everyone happy.

-- 
MacPorts boost lib not detected on OS X
https://bugs.launchpad.net/bugs/481833
You received this bug notification because you are a member of LinuxDC++
Team, which is subscribed to LinuxDC++.

Status in Linux DC++: Fix Committed

Bug description:
Hi,

Tested with latest bzr repository, after installing all dependencies via MacPorts 1.8.1, 
this error remains when launching build with scons:
---
...
Checking for C++ header file boost/version.hpp... no
	boost not found.
	Note: You might have the lib but not the headers
---
boost headers *are* installed in /opt/local/include/boost/*, but it's not picked.
(all other MacPorts dependencies are recognized)

If I comment out the check in SConstruct and add -I/opt/local/include to CXXFLAGS, 
it builds correctly.