legacy-support: Minor issues with ARCHFLAGS in the Makefile

[TurtleWilly (Wilhelm Loves Their Turtles)]

Not a real problem, and easy to workaround, but I wanted to report it anyway.

In the Makefile it does the following:

FORCE_ARCH      ?=
ARCHFLAGS       ?=
LIPO            ?= lipo
CC              ?= cc $(ARCHFLAGS)
CFLAGS          ?= -Os -Wall -Wno-deprecated-declarations
DLIBCFLAGS      ?= -fPIC
SLIBCFLAGS      ?=
CXX             ?= c++ $(ARCHFLAGS)
CXXFLAGS        ?= -Os -Wall

So building with "make FORCE_ARCH=i368 ARCHFLAGS='-arch i368'" I expected to get a proper i386 build of the library, but I ended up with a x86_64 one anyway. It seems that "$(ARCHFLAGS)" is not expanded in the "CC ?= …" and "CXX ?= …" lines and simply ends up empty, hence the it progresses with a native arch build. Switching both lines from "?=" to just "=" makes things work (ultimately I just passed CC and CXX including the arch parameter as arguments to make instead using the ARCHFLAGS variable).

$ make --version
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for i386-apple-darwin11.3.0

(XCode 7.2/ OS X 10.10.5 Yosemite)

Unrelated to the actual issue above I think the BUILDING.txt could need some clarification how things work. I sounds a bit confusing. E.g. I assumed it would work with just FORCE_ARCH. It also could mention the supported arches, so one doesn't have to dig it out of the Makefile source code.

[ryandesign (Ryan Carsten Schmidt)]

Replying to TurtleWilly:

It seems that "$(ARCHFLAGS)" is not expanded in the "CC ?= …" and "CXX ?= …" lines and simply ends up empty,

I would have thought it would get expanded.

CC              ?= cc $(ARCHFLAGS)

CXX             ?= c++ $(ARCHFLAGS)

But even if it did, this doesn't seem like a good way to do it. Users expect to be able to override CC and CXX, and they don't expect that, when they do so, some flags will no longer get added.

[ryandesign (Ryan Carsten Schmidt)]

I would think something more like

CC              := $(CC) $(ARCHFLAGS)

CXX             := $(CXX) $(ARCHFLAGS)

but this is untested and still not ideal. Instead, $(ARCHFLAGS) should be in each rule that needs it.

(make defaults to cc and c++ for CC and CXX respectively, doesn't it? So providing that value should not be necessary.)

[TurtleWilly (Wilhelm Loves Their Turtles)]

This is how it would resolve here on my system:

$ make --print-data-base | egrep '^(CC|CXX).*'
CC = cc
CXX = c++

$ which cc
/usr/bin/cc
$ which c++
/usr/bin/c++

$ ls -l /usr/bin/cc
lrwxr-xr-x  1 root  wheel  5 Oct 30  2014 /usr/bin/cc -> clang
$ ls -l /usr/bin/c++
lrwxr-xr-x  1 root  wheel  7 Oct 30  2014 /usr/bin/c++ -> clang++

And finally clang and clang++ are shim binaries that redirect to inside XCode, if installed, or prompt the user to install XCode first. Redirection madness. :)

[fhgwright (Fred Wright)]

I've seen cases where specifying the arch flag(s) in the usual C*FLAGS doesn't work and it *must* be done in CC or CXX, though admittedly that doesn't seem to be the case here. But I normally use a wrapper script to build legacy-support anyway. The script I use is set up to pick reasonable defaults on every system, though you can override them if you want. The one thing it doesn't do is use FORCE_ARCH, since in this context it's easier just to have the MacPorts cctools active on the systems where the system lipo is inadequate. The port avoids that for dependency reasons.

With this script I usually just say something like:

../.scripts/lscc.sh make

That works on all systems.

I'll attach a copy of the script.

[fhgwright (Fred Wright)]

Wrapper script for building legacy-support

[fhgwright (Fred Wright)]

I should point out that the default for ARCH only works if you've set build_arch explicitly in macports.conf, which I usually do anyway for clarity (and because the default sometimes doesn't agree with the documentation).

But if you set ARCH explicitly it doesn't matter.