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

[Michael]

On 2017-07-05, at 6:16 AM, Jan Stary  wrote:

> On Jul 05 08:38:16, a...@alum.wpi.edu 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

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

[Jan Stary]

On Jul 05 08:38:16, a...@alum.wpi.edu wrote:
> On Wed, Jul 5, 2017 at 7:14 AM, Jan Stary  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

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

[Jan Stary]

On Jul 03 21:21:36, jerem...@macports.org 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

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

[Jan Stary]

On Jul 04 03:10:38, ryandes...@macports.org 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

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

[Jeremy Huddleston Sequoia]

> On Jul 4, 2017, at 01:10, Ryan Schmidt  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