Dropping recommendation to install system headers / command line tools

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Dropping recommendation to install system headers / command line tools

Jeremy Huddleston Sequoia
base currently outputs a warning if system headers are not installed.  I modified the warning a few months ago when I improved our support for building against SDKs, and it now reads:

   Warning: System headers do not appear to be installed. Most ports should build corectly, but if you experience problems due to a port depending on system headers, please file a ticket at https://trac.macports.org.
   Warning: You can install them as part of the Xcode Command Line Tools package by running `xcode-select --install'.

How many developers are using Xcode with the system headers installed vs without system headers?  If you are using system headers (currently installed through the CLTools package and through similar means on older OS versions), can you please indicate why you are unable to use an SDK?  I haven't seen any tickets about issues when using an SDK over system headers, and the only issue I'm aware of is with gcc ports (which is an upstream bug and mostly worked around).

I'd like to remove this warning in order to indicate that building against an SDK is now a more supported configuration.  IMO, it should be the *preferred* configuration as it avoids /usr/local/{include,lib} contamination.  What are the thoughts on this?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dropping recommendation to install system headers / command line tools

Ryan Schmidt-24

On Jul 3, 2017, at 23:21, Jeremy Huddleston Sequoia wrote:

> base currently outputs a warning if system headers are not installed.  I modified the warning a few months ago when I improved our support for building against SDKs, and it now reads:
>
>   Warning: System headers do not appear to be installed. Most ports should build corectly, but if you experience problems due to a port depending on system headers, please file a ticket at https://trac.macports.org.
>   Warning: You can install them as part of the Xcode Command Line Tools package by running `xcode-select --install'.
>
> How many developers are using Xcode with the system headers installed vs without system headers?  If you are using system headers (currently installed through the CLTools package and through similar means on older OS versions), can you please indicate why you are unable to use an SDK?  I haven't seen any tickets about issues when using an SDK over system headers, and the only issue I'm aware of is with gcc ports (which is an upstream bug and mostly worked around).
>
> I'd like to remove this warning in order to indicate that building against an SDK is now a more supported configuration.  IMO, it should be the *preferred* configuration as it avoids /usr/local/{include,lib} contamination.  What are the thoughts on this?

Last I checked, graphite2 would not build if CLTools were not installed:

https://trac.macports.org/ticket/49325

I don't know how many other ports are in the same situation.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dropping recommendation to install system headers / command line tools

Jeremy Huddleston Sequoia

> On Jul 4, 2017, at 01:10, Ryan Schmidt <[hidden email]> wrote:
>
>
> On Jul 3, 2017, at 23:21, Jeremy Huddleston Sequoia wrote:
>
>> base currently outputs a warning if system headers are not installed.  I modified the warning a few months ago when I improved our support for building against SDKs, and it now reads:
>>
>>  Warning: System headers do not appear to be installed. Most ports should build corectly, but if you experience problems due to a port depending on system headers, please file a ticket at https://trac.macports.org.
>>  Warning: You can install them as part of the Xcode Command Line Tools package by running `xcode-select --install'.
>>
>> How many developers are using Xcode with the system headers installed vs without system headers?  If you are using system headers (currently installed through the CLTools package and through similar means on older OS versions), can you please indicate why you are unable to use an SDK?  I haven't seen any tickets about issues when using an SDK over system headers, and the only issue I'm aware of is with gcc ports (which is an upstream bug and mostly worked around).
>>
>> I'd like to remove this warning in order to indicate that building against an SDK is now a more supported configuration.  IMO, it should be the *preferred* configuration as it avoids /usr/local/{include,lib} contamination.  What are the thoughts on this?
>
> Last I checked, graphite2 would not build if CLTools were not installed:
>
> https://trac.macports.org/ticket/49325

It builds just fine for me.  That report seems to predate the relevant changes in base to pick an SDK if the DevSDK ("System Headers") isn't present.

> I don't know how many other ports are in the same situation.

None of these ports seem to have any issues:

ImageMagick
Xft2
XviD
a52dec
aalib
accountsservice
ack
adwaita-icon-theme
appres
appstream-glib
apr
apr-util
asciidoc
at-spi2-atk
at-spi2-core
atk
atkmm
audiofile
autoconf
autoconf-archive
autoconf213
automake
avahi
babl
baobab
bash
bash-completion
bdftopcf
bison
bison-runtime
bitmap
boehmgc
boost
bsdmake
bzip2
c-ares
cabextract
cairo
cairomm
cctools
cd-discid
cdparanoia
cfitsio
chromaprint
clang-3.7
clang-3.8
clang-3.9
clang-4.0
clang-devel
clang_select
clutter
clutter-gst
clutter-gst3
clutter-gtk
cmake
cogl
coreutils
cracklib
ctags
curl
curl-ca-bundle
cvs
cyrus-sasl2
cython_select
db46
db48
db53
db60
dbus
dbus-glib
dbus-python27
dbus-python34
dconf
dconf-editor
dcraw
desktop-file-utils
devhelp
diffutils
djvulibre
docbook-xml
docbook-xml-4.1.2
docbook-xml-4.2
docbook-xml-4.3
docbook-xml-4.4
docbook-xml-4.5
docbook-xml-5.0
docbook-xsl
dos2unix
dosbox
doxygen
editres
emacs
enchant
eog
epiphany
esound
evince
evolution-data-server
exempi
exiv2
expat
faac
faad2
fetchmail
ffmpeg
fftw-3
fftw-3-single
file
file-roller
findutils
flac
flex
fluidsynth
folks
font-adobe-100dpi
font-adobe-75dpi
font-adobe-utopia-100dpi
font-adobe-utopia-75dpi
font-adobe-utopia-type1
font-alias
font-arabic-misc
font-bh-100dpi
font-bh-75dpi
font-bh-lucidatypewriter-100dpi
font-bh-lucidatypewriter-75dpi
font-bh-ttf
font-bh-type1
font-bitstream-100dpi
font-bitstream-75dpi
font-bitstream-speedo
font-bitstream-type1
font-cronyx-cyrillic
font-cursor-misc
font-daewoo-misc
font-dec-misc
font-ibm-type1
font-isas-misc
font-jis-misc
font-micro-misc
font-misc-cyrillic
font-misc-ethiopic
font-misc-meltho
font-misc-misc
font-mutt-misc
font-schumacher-misc
font-screen-cyrillic
font-sony-misc
font-sun-misc
font-winitzki-cyrillic
font-xfree86-type1
fontconfig
fonttosfnt
fop
freeglut
freetype
fribidi
fslsfonts
fstobdf
gawk
gcab
gcc6
gcc_select
gconf
gcr
gd2
gdbm
gdk-pixbuf2
gedit
gegl
gegl-0.3
geoclue2
geocode-glib
getopt
gettext
gexiv2
gfbgraph
ghex
ghostscript
giflib
gimp
gimp-app
gimp-jp2
gimp-lqr-plugin
gimp2
gindent
git
gitg
gjs
glade
glib-networking
glib2
glibmm
glxgears
glxinfo
gmake
gmime
gmp
gnome
gnome-autoar
gnome-backgrounds
gnome-calculator
gnome-calendar
gnome-characters
gnome-chess
gnome-common
gnome-control-center
gnome-desktop
gnome-devel-docs
gnome-dictionary
gnome-doc-utils
gnome-font-viewer
gnome-getting-started-docs
gnome-js-common
gnome-keyring
gnome-maps
gnome-menus
gnome-music
gnome-online-accounts
gnome-online-miners
gnome-photos
gnome-session
gnome-settings-daemon
gnome-sudoku
gnome-terminal
gnome-themes-standard
gnome-user-docs
gnome-weather
gnome3-apps
gnome3-core
gnupg
gnupg2
gnutls
gobject-introspection
gpatch
gperf
gpg-agent
gpgme
graphene
graphite2
graphviz
grep
grilo
grilo-plugins
groff
gsed
gsettings-desktop-schemas
gspell
gssdp
gstreamer1
gstreamer1-gst-libav
gstreamer1-gst-plugins-bad
gstreamer1-gst-plugins-base
gstreamer1-gst-plugins-good
gstreamer1-gst-plugins-ugly
gtk-doc
gtk-engines2
gtk2
gtk3
gtkimageview
gtkmm3
gtksourceview3
gtkspell3
gts
gupnp
gupnp-av
gupnp-dlna
gupnp-igd
gutenprint
gvfs
gzip
harfbuzz
harfbuzz-icu
help2man
hicolor-icon-theme
hyphen
iceauth
ico
icon-naming-utils
icu
id3lib
id3v2
ilmbase
imlib2
intltool
isl
iso-codes
itstool
jack
jasper
jbig2dec
jbigkit
jpeg
json-glib
kerberos5
lame
lcms
lcms2
ld64
ld64-127
ld64-236
ld64-latest
ld64-xcode
lensfun
libGLU
libLASi
libao
libarchive
libass
libassuan
libatomic_ops
libbluray
libcaca
libcanberra
libcddb
libcdio
libchamplain
libcomerr
libcroco
libcxx
libdaemon
libdca
libdv
libdvdcss
libdvdnav
libdvdread
libedit
libepoxy
libev
libevent
libexif
libffi
libgcc
libgcrypt
libgdata
libgee
libgeoip
libgit2
libgit2-glib
libglade2
libgnome-keyring
libgnomekbd
libgpg-error
libgrss
libgsf
libgtop
libgweather
libical
libiconv
libid3tag
libidl
libidn
libiptcdata
libksba
liblqr
libmacho-headers
libmad
libmagic
libmediaart
libmms
libmng
libmodplug
libmpc
libmpcdec
libmpeg2
libnetpbm
libnotify
liboauth
libogg
liboil
libomp
libopenraw
libopus
libpaper
libpcap
libpeas
libphonenumber-cpp
libpixman
libpng
libproxy
libpwquality
libquicktime-devel
libquvi
libquvi-scripts
libraw
libressl-devel
librsvg
libsamplerate
libsdl
libsdl2
libsdl_net
libsdl_sound
libsecret
libshout2
libsigcxx2
libsmi
libsndfile
libsocialweb
libsoup
libspectre
libspiro
libssh2
libtasn1
libtheora
libtool
libunistring
libusb
libusb-compat
libuv
libvorbis
libvpx
libwmf
libwnck3
libxklavier
libxml2
libxslt
libyaml
libzzip
lighttpd
links
listres
llvm-3.7
llvm-3.8
llvm-3.9
llvm-4.0
llvm-devel
llvm_select
lua
lua-lpeg
lua-luabitop
lua-luaexpat
lua-luajson
lua-luasocket
luit
lynx
lz4
lzo2
m4
mercurial
mesa
metacity
midori
mkfontdir
mkfontscale
mm-common
mozjs17
mozjs24
mozplugger
mpfr
mpg123
mplayer-devel
mysql57
mysql_select
nano
nautilus
ncurses
neon
net-snmp
netpbm
nettle
normalize
nosetests_select
nspr
nss
oclock
openal-soft
opencore-amr
openexr
openjade
openjpeg
openjpeg15
openldap
opensp
openssh
opus-tools
orbit2
orc
p11-kit
p5-test-harness
p5-yaml-syck
p5.24-authen-sasl
p5.24-capture-tiny
p5.24-cgi
p5.24-cpan-meta-requirements
p5.24-devel-checkbin
p5.24-digest-hmac
p5.24-digest-sha1
p5.24-encode-locale
p5.24-error
p5.24-extutils-makemaker
p5.24-extutils-manifest
p5.24-file-listing
p5.24-file-next
p5.24-getopt-long
p5.24-gssapi
p5.24-html-form
p5.24-html-parser
p5.24-html-tagset
p5.24-http-cookies
p5.24-http-daemon
p5.24-http-date
p5.24-http-message
p5.24-http-negotiate
p5.24-io
p5.24-io-html
p5.24-io-socket-inet6
p5.24-io-socket-ip
p5.24-io-socket-ssl
p5.24-libwww-perl
p5.24-locale-gettext
p5.24-lwp-mediatypes
p5.24-lwp-protocol-https
p5.24-mime-base64
p5.24-mozilla-ca
p5.24-net-http
p5.24-net-libidn
p5.24-net-smtp-ssl
p5.24-net-ssleay
p5.24-pathtools
p5.24-scalar-list-utils
p5.24-socket
p5.24-socket6
p5.24-sub-name
p5.24-sub-uplevel
p5.24-svn-simple
p5.24-term-readkey
p5.24-test-deep
p5.24-test-exception
p5.24-test-fatal
p5.24-test-harness
p5.24-test-nowarnings
p5.24-test-requiresinternet
p5.24-test-warn
p5.24-try-tiny
p5.24-uri
p5.24-www-robotrules
p5.24-xml-namespacesupport
p5.24-xml-parser
p5.24-xml-sax
p5.24-xml-sax-base
p5.24-xml-sax-expat
p5.24-xml-simple
p5.24-yaml-syck
pango
pangomm
pari
pcre
pcre2
perl5
perl5.24
physfs
pidof
pinentry-mac
pkgconfig
polari
policykit
poppler
poppler-data
popt
portaudio
potrace
protobuf-cpp
pstree
psutils
pth
pulseaudio
py27-beaker
py27-cairo
py27-cython
py27-docutils
py27-gdbm
py27-gitdb
py27-gitpython
py27-gobject
py27-gobject3
py27-html5lib
py27-isodate
py27-libxml2
py27-mako
py27-markupsafe
py27-nose
py27-numpy
py27-pygtk
py27-pysvn
py27-rdflib
py27-roman
py27-setuptools
py27-simplejson
py27-six
py27-smmap
py27-twisted
py27-tz
py27-webencodings
py27-zopeinterface
py34-astroid
py34-cairo
py34-certifi
py34-chardet
py34-cython
py34-flake8-mccabe
py34-gobject3
py34-idna
py34-isort
py34-lazy_object_proxy
py34-logilab-common
py34-nose
py34-numpy
py34-py
py34-pylint
py34-pytest
py34-pytest-runner
py34-requests
py34-setuptools
py34-setuptools_scm
py34-six
py34-urllib3
py34-wrapt
pylint_select
python27
python2_select
python34
python35
python36
python3_select
python_select
qqwing
quartz-wm
raptor2
rarian
readline
rendercheck
rest
rgb
rsync
rtmpdump
ruby
ruby23
ruby24
ruby_select
rxvt-unicode
rygel
samba3
sane-backends
schroedinger
scons
seahorse
serf1
sessreg
setxkbmap
shared-mime-info
showfont
smpeg
smproxy
sound-theme-freedesktop
soundtouch
source-highlight
soxr
spandsp-devel
spawn-fcgi
speex
speexDSP
sqlite3
startup-notification
subversion
subversion-perlbindings-5.24
swig
swig-ruby
taglib
tcp_wrappers
telepathy-glib
telepathy-idle
telepathy-logger
telepathy-mission-control
texinfo
texlive-basic
texlive-bin
texlive-common
tiff
tig
totem
totem-pl-parser
tracker
tradcpp
transcode
transset
twm
twolame
ufraw
uhttpmock
uncrustify
unrar
upower
urw-fonts
vala
viewres
vino
vorbis-tools
vte
w3m
wavpack
webkit-gtk
webkit2-gtk-devel
webp
wget
wine-devel
winetricks
wireshark
wol
x11perf
x264
x265
xar
xauth
xbacklight
xbitmaps
xcalc
xclipboard
xclock
xcmsdb
xcompmgr
xconsole
xcursorgen
xditview
xdm
xdpyinfo
xedit
xev
xeyes
xfd
xfindproxy
xfontsel
xfs
xfsinfo
xgamma
xgc
xhost
xinit
xinput
xkbcomp
xkbevd
xkbprint
xkbutils
xkeyboard-config
xkill
xload
xlogo
xlsatoms
xlsclients
xlsfonts
xmag
xman
xmessage
xmh
xmlcatmgr
xmlto
xmodmap
xmore
xorg
xorg-applewmproto
xorg-apps
xorg-bigreqsproto
xorg-compositeproto
xorg-damageproto
xorg-dmxproto
xorg-dri2proto
xorg-encodings
xorg-fixesproto
xorg-font-util
xorg-fontcacheproto
xorg-fonts
xorg-fontsproto
xorg-glproto
xorg-inputproto
xorg-kbproto
xorg-libAppleWM
xorg-libFS
xorg-libX11
xorg-libXScrnSaver
xorg-libXTrap
xorg-libXau
xorg-libXaw
xorg-libXcomposite
xorg-libXcursor
xorg-libXdamage
xorg-libXdmcp
xorg-libXext
xorg-libXfixes
xorg-libXfont
xorg-libXfont2
xorg-libXfontcache
xorg-libXi
xorg-libXinerama
xorg-libXmu
xorg-libXp
xorg-libXrandr
xorg-libXres
xorg-libXt
xorg-libXtst
xorg-libXv
xorg-libXxf86misc
xorg-libXxf86vm
xorg-libdmx
xorg-libfontenc
xorg-libice
xorg-libpthread-stubs
xorg-libsm
xorg-libxcb
xorg-libxkbfile
xorg-presentproto
xorg-printproto
xorg-randrproto
xorg-recordproto
xorg-renderproto
xorg-resourceproto
xorg-scripts
xorg-scrnsaverproto
xorg-server-devel
xorg-trapproto
xorg-util-macros
xorg-videoproto
xorg-xcb-proto
xorg-xcb-util
xorg-xcmiscproto
xorg-xextproto
xorg-xf86bigfontproto
xorg-xf86miscproto
xorg-xf86vidmodeproto
xorg-xineramaproto
xorg-xproto
xorg-xproxymanagementprotocol
xorg-xtrans
xpm
xpr
xprop
xrandr
xrdb
xrefresh
xrender
xsane
xset
xsetmode
xsetpointer
xsetroot
xsm
xstdcmap
xterm
xtrap
xvinfo
xwd
xwininfo
xwud
xz
yasm
yelp
yelp-tools
yelp-xsl
zeitgeist
zenity
zip
zlib


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dropping recommendation to install system headers / command line tools

Jan Stary
In reply to this post by Ryan Schmidt-24
On Jul 04 03:10:38, [hidden email] wrote:
> Last I checked, graphite2 would not build if CLTools were not installed:
> https://trac.macports.org/ticket/49325

On a related note: a comment in this ticket says that

        xcode-select -p does not show whether you have
        the command line tools installed.

Yet that's exactly what "port diagnose" uses.
https://trac.macports.org/ticket/53909

        Jan

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dropping recommendation to install system headers / command line tools

Jan Stary
In reply to this post by Jeremy Huddleston Sequoia
On Jul 03 21:21:36, [hidden email] wrote:
> base currently outputs a warning if system headers are not installed.  I modified the warning a few months ago when I improved our support for building against SDKs, and it now reads:
>
>    Warning: System headers do not appear to be installed. Most ports should build corectly, but if you experience problems due to a port depending on system headers, please file a ticket at https://trac.macports.org.
>    Warning: You can install them as part of the Xcode Command Line Tools package by running `xcode-select --install'.
>
> How many developers are using Xcode with the system headers installed vs without system headers?

It's a UNIX system. I want it to have /usr/include/unistd.h etc.

> If you are using system headers (currently installed through the CLTools package and through similar means on older OS versions), can you please indicate why you are unable to use an SDK?

The question seems to imply that I should _not_ use system headers
unless I absolutely have to. That puzzles me.

> I haven't seen any tickets about issues when using an SDK over system headers,
> and the only issue I'm aware of is with gcc ports (which is an upstream bug and mostly worked around).

Even if failing to build a compiler is "the only issue", it's a pretty major one, no?
GNU does not even consider it a proper bug yet (it's UNCONFORMED):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885

> I'd like to remove this warning in order to indicate that building against an SDK is now a more supported configuration.  IMO, it should be the *preferred* configuration

Why?

> as it avoids /usr/local/{include,lib} contamination.  What are the thoughts on this?

What contamination? I don't even have /usr/local/

        Jan

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dropping recommendation to install system headers / command line tools

Arno Hautala
On Wed, Jul 5, 2017 at 7:14 AM, Jan Stary <[hidden email]> wrote:
>> as it avoids /usr/local/{include,lib} contamination.  What are the thoughts on this?
>
> What contamination? I don't even have /usr/local/

You may not have /usr/local, but lots of people do. It's the default
installation prefix when compiling most 3rd party tools and there are
other 3rd party software installers that pick this path as well.

The issue is that libraries installed here may be picked up instead of
those installed by MacPorts in /opt/local. A lot of effort has been
expanded looking for ways to explicitly exclude those libraries (I'm
not sure of how complete or effective this is right now).

I wonder though, would relying on having not installed the headers
make things worse? Right now it seems MP assumes /usr/local needs to
be hidden or excluded. Presuming it's not there would be a step back.
Am I mis-interpreting here?

--
arno  s  hautala    /-|   [hidden email]

pgp b2c9d448
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dropping recommendation to install system headers / command line tools

Rainer Müller-4
In reply to this post by Jeremy Huddleston Sequoia
On 2017-07-04 06:21, Jeremy Huddleston Sequoia wrote:
> base currently outputs a warning if system headers are not installed.  I modified the warning a few months ago when I improved our support for building against SDKs, and it now reads:
>
>    Warning: System headers do not appear to be installed. Most ports should build corectly, but if you experience problems due to a port depending on system headers, please file a ticket at https://trac.macports.org.
>    Warning: You can install them as part of the Xcode Command Line Tools package by running `xcode-select --install'.
>
> How many developers are using Xcode with the system headers installed vs without system headers?  If you are using system headers (currently installed through the CLTools package and through similar means on older OS versions), can you please indicate why you are unable to use an SDK?  I haven't seen any tickets about issues when using an SDK over system headers, and the only issue I'm aware of is with gcc ports (which is an upstream bug and mostly worked around).

I guess almost everyone has the Command Line Tools installed, if not
only to get rid of this warning...

I do not remember all the details on how it was done on older OS X
release, but originally there were no shims. I think there were some
problems if someone had Command Line Tools installed, but not install
them again after upgrading Xcode. Let's just leave old versions as-is
and only remove these warnings for macOS 10.12 Sierra and later, where
we get the most testing.

We should also add to port log files whether Xcode, Command Line Tools
or both were installed in order to identify such issues.

> I'd like to remove this warning in order to indicate that building against an SDK is now a more supported configuration.  IMO, it should be the *preferred* configuration as it avoids /usr/local/{include,lib} contamination.  What are the thoughts on this?

Does this mean we have to ensure we always pass -isysroot and
-syslibroot on all builds? Currently it is only added for those running
a configure phase...

Rainer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dropping recommendation to install system headers / command line tools

Jan Stary
In reply to this post by Arno Hautala
On Jul 05 08:38:16, [hidden email] wrote:
> On Wed, Jul 5, 2017 at 7:14 AM, Jan Stary <[hidden email]> wrote:
> >> as it avoids /usr/local/{include,lib} contamination.  What are the thoughts on this?
> >
> > What contamination? I don't even have /usr/local/
>
> You may not have /usr/local, but lots of people do. It's the default
> installation prefix when compiling most 3rd party tools and there are
> other 3rd party software installers that pick this path as well.

Of course; on most other UNIX systems, I install in /usr/local.
But one of the first things you come across when using MacPorts
is that you are not supposed to have anything in /usr/local

https://trac.macports.org/wiki/FAQ#defaultprefix
https://trac.macports.org/wiki/FAQ#usrlocal

        Can I install software in /usr/local while using MacPorts?
        No. ...


> The issue is that libraries installed here may be picked up instead of
> those installed by MacPorts in /opt/local.

Yes. I still believe that's exactly why MP should use /usr/local,
like most other systems do; but that's hardly gonna happen.

> I wonder though, would relying on having not installed the headers
> make things worse?

It's a UNIX system. Why would you rely on e.g.
/usr/include/unistd.h _not_ being there?

> Right now it seems MP assumes /usr/local needs to
> be hidden or excluded.

The FAQ explicitly says you should not install anything in there.

        Jan

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dropping recommendation to install system headers / command line tools

Michael_google gmail_Gersten

On 2017-07-05, at 6:16 AM, Jan Stary <[hidden email]> wrote:

> On Jul 05 08:38:16, [hidden email] wrote:
> https://trac.macports.org/wiki/FAQ#defaultprefix
> https://trac.macports.org/wiki/FAQ#usrlocal
>
> Can I install software in /usr/local while using MacPorts?
> No. ...
>
>
>> The issue is that libraries installed here may be picked up instead of
>> those installed by MacPorts in /opt/local.
>
> Yes. I still believe that's exactly why MP should use /usr/local,
> like most other systems do; but that's hardly gonna happen.
>
> ...
>> Right now it seems MP assumes /usr/local needs to
>> be hidden or excluded.
>
> The FAQ explicitly says you should not install anything in there.
>
> Jan

Ok, what do you do if you install a premade program from elsewhere that does want to stuff something in /usr/local?

Right now, I have in there:
Jack2
Git-flow
... a bunch of stuff I don't recognize
rtmpdump (and librtmp)
a symlink for sdl2 that points to the mac ports sdl (all those programs that assume brew put it in /usr/local).
graphviz (???)

Yea, compilers that assume /usr/local must be searched for include files are broken. Other than that, what else is the issue?

---
Entertaining minecraft videos
http://YouTube.com/keybounce

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dropping recommendation to install system headers / command line tools

Kenneth F. Cunningham
>
> Yea, compilers that assume /usr/local must be searched for include files are broken. Other than that, what else is the issue?
>
> —


I wasn’t around for it, but I think in the beginning /opt/local was chosen for macports in part because /usr/local was being heavily used by darwinbuild and they needed to keep away from that.

Also, other installers tend to dump things in there by default and overwrite things.

Years went by. darwinbuild is rarely used. homebrew decided to go for /usr/local, and accept the occasional dump in there by some installers. macports was already invested in /opt/local, and stayed there.


IF you have stuff in /usr/local you may not have problems for some times — but then one day, you will try to install something with macports, and you will get a failure you can’t sort out. You’ll post a ticket, somebody will eventually figure out you have polluted /usr/local, ask you to empty it out, and your macports build with then succeed.

And then you go down -100 points on the “macports” index :>

Ken
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dropping recommendation to install system headers / command line tools

Rainer Müller-4
On 2017-07-05 18:28, Ken Cunningham wrote:
> I wasn’t around for it, but I think in the beginning /opt/local was chosen for macports in part because /usr/local was being heavily used by darwinbuild and they needed to keep away from that.

There are several reasons not to use /usr/local:

Lots of graphical installers will install files to /usr/local. When
unexperienced users follow instructions on how to install software, they
are likely to put stuff into /usr/local that will later conflict with
MacPorts. Similarly, you are not supposed to manually build and install
software with './configure --prefix=/opt/local' if this prefix is
managed by MacPorts.

/usr/local/{include,lib} cannot be removed from the search paths of the
compiler, so you would no longer be able to compile anything without
opportunistically linking to MacPorts.

Most notably, /usr/local/bin is in the default system PATH. By
installing incompatbile binaries with the same names as system binaries,
you may break third-party or system scripts. Therefore it is better to
use a separate prefix that is not in the default PATH, but can be added
for interactive shells only.

Fink and MacPorts chose a different prefix to avoid these problems and
conflicts. They can coexist as long as software build scripts do not
hardcode /sw or /opt/local (we usually patch it out if encountered).
Homebrew just did not care about previous experiences and chose to use
/usr/local.

Rainer
Loading...