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: Buildbot now fails to build wine dependencies

[Clemens Lang]

Hi,

On Tue, Jul 04, 2017 at 04:23:13PM +0200, Rainer Müller wrote:
> I still don't understand why we pass *default* variants to
> dependencies at all. As I see it, the problem would go away if we
> would not request default variants explicitly...
> 
> @Clemens,
> as you originally added this to mpbb/tools/dependencies.tcl, do you
> still remember the reason?

You were right on it when you mentioned the failcache. However, you only
considered the reading part of the failcache, not the writing part of
it.

We need to know the canonical (i.e., fully-expanded) set of variants for
every port we build, because even when a port is only installed as a
dependency, we update the failcache when it fails.

Failure to do this would possibly cache a build failure of what mpbb
thinks is 'cairo +quartz' (but actually is 'cairo +quartz+x11') cached
for 'cairo +quartz-x11' (i.e. canonically 'cairo +quartz').


> I am attaching a patch to only print active variants that are not
> enabled by default (or disabled default variants). To me the result
> looks like what we want to have:
> 
> $ tools/dependencies.tcl wine | grep -E 'glib2|cairo'
> glib2 +universal
> cairo +universal
> $ tools/dependencies.tcl gtk3 +quartz | grep -E 'glib2|cairo'
> glib2 +quartz
> cairo

No, this won't work, because with this output you can no longer
distinguish 'cairo (default variants)' from 'cairo -quartz-x11'. This is
probably not a valid configuration for the cairo port specifically, but
you get the idea.

I think a patch that does not return a default variant if a conflicting
other variant was selected should work fine, though (and is exactly what
MacPorts itself would do in these situations, afaik).

-- 
Clemens

Re: Is it time for a libc_fixes library yet?

[Ken Cunningham]

> 
> 
> Perfect would be if I just wrote it into the clang code directly. I am almost 
> to the point where I could do that, actually. I know where it would go, I 
> think.
> 

Well, another fairly easy option would be to bring down the newer libc from 
10.7 and port it back into 10.4 to 10.6, with some mods to the headers to 
support the new functions.  That would also be quite doable.  But  who knows 
what that would break ?

I know that is a total non-starter, so I didn't bother.

K

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

Re: Is it time for a libc_fixes library yet?

[Ryan Schmidt]

On Jul 3, 2017, at 12:07, Ken Cunningham wrote:

> As we have said before (last year) this library could be automatically linked 
> in by base. That would cause trouble with the ports that have already patched 
> in a def, tho.

Your library offers multiple functions... getline, strndup, etc.

What happens if a software package provides, for example, a compatibility 
implementation of getline but not strndup? Can your library be used in this 
case or will that also "cause trouble", as you put it above?


I see the port and a portgroup have been added to MacPorts. I would like to 
request that each port that adopts this port/portgroup also add a comment 
explaining upstream's stance on the issue. For example, a link to the upstream 
bug report.

Re: [macports-ports] branch master updated: snowleopardfixes: new port to deal with missing functions in Snow Leopard

[Ryan Schmidt]

> On Jul 3, 2017, at 14:46, Marius Schamschula  wrote:
> 
> Marius Schamschula (Schamschula) pushed a commit to branch master
> in repository macports-ports.
> 
> https://github.com/macports/macports-ports/commit/3efea307091e06b1176c8e9c1f771dd1efdea179
>  
> 
> The following commit(s) were added to refs/heads/master by this push:
>  new 3efea30  snowleopardfixes: new port to deal with missing functions 
> in Snow Leopard
> 3efea30 is described below
> 
> commit 3efea307091e06b1176c8e9c1f771dd1efdea179
> Author: Marius Schamschula 
> AuthorDate: Mon Jul 3 14:46:31 2017 -0500
> 
> snowleopardfixes: new port to deal with missing functions in Snow Leopard
> ---
>  devel/snowleopardfixes/Portfile | 31 +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/devel/snowleopardfixes/Portfile b/devel/snowleopardfixes/Portfile
> new file mode 100644
> index 000..d628fc9
> --- /dev/null
> +++ b/devel/snowleopardfixes/Portfile
> @@ -0,0 +1,31 @@
> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
> +
> +PortSystem  1.0
> +PortGroup   github 1.0
> +PortGroup   muniversal 1.0

Why muniversal?

> +#PortGroup  cmake 1.0
> +
> +github.setupkencu snowleopardfixes 
> 72c90d36d20023eab306b1f9be077c5e11c3fc58
> +version 20170702
> +categories  sysutils
> +platforms   darwin
> +maintainers gmail.com:ken.cunningham.webuse
> +license GPL-2
> +
> +description A library to replace common functions missing from 
> SnowLeopard
> +long_description${description}
> +
> +checksums   rmd160  43303d2c290455488a806b05fe22647b8b070e63 \
> +sha256  
> b73fdaed13fb50a437cd5cbe530096f9afb921820ce1dcd292bc367470888b46
> +
> +use_configure   no
> +
> +
> +build.env   CXX="${configure.cxx}" \
> +CXXFLAGS="${configure.cxxflags} [get_canonical_archflags 
> cxx]" \
> +CC="${configure.cc}" \
> +CFLAGS="${configure.cflags}" \
> +LDFLAGS="${configure.ldflags}  [get_canonical_archflags 
> ld]" \
> +PREFIX=${prefix}
get_canonical_archflags won't do the right thing with muniversal. Look in the 
log and note how the "x86_64" build and the "i386" build both build for both 
x86_64 and i386.

The fact that the universal build succeeds and actually produces universal 
binaries suggests the muniversal portgroup isn't needed. All you need is 
"variant universal {}" after "use_configure no".

Re: [macports-ports] 01/02: New PortGroup snowleopard_fixes

[Ryan Schmidt]

> On Jul 3, 2017, at 14:59, Marius Schamschula  wrote:
> 
> Marius Schamschula (Schamschula) pushed a commit to branch master
> in repository macports-ports.
> 
> https://github.com/macports/macports-ports/commit/273304d02313f76225a1d5db7be911bf5e2b34f6
>  
> 
> commit 273304d02313f76225a1d5db7be911bf5e2b34f6
> Author: Marius Schamschula 
> AuthorDate: Mon Jul 3 14:57:09 2017 -0500
> 
> New PortGroup snowleopard_fixes
> ---
>  _resources/port1.0/group/snowleopard_fixes-1.0.tcl | 41 
> ++
>  1 file changed, 41 insertions(+)
> 
> diff --git a/_resources/port1.0/group/snowleopard_fixes-1.0.tcl 
> b/_resources/port1.0/group/snowleopard_fixes-1.0.tcl
> new file mode 100644
> index 000..c3dda91
> --- /dev/null
> +++ b/_resources/port1.0/group/snowleopard_fixes-1.0.tcl
> @@ -0,0 +1,41 @@
> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
> +#
> +# Copyright (c) 2009 Rainer Mueller 
> +# Copyright (c) 2009-2012, 2015-2017 The MacPorts Project
> +# All rights reserved.

Can we fix the copyright information?

Re: [macports-base] 01/02: portconfigure: Put a space between -isysroot and the path

[Ryan Schmidt]

> On Jul 3, 2017, at 23:04, Jeremy Huddleston Sequoia  
> wrote:
> 
> Jeremy Huddleston Sequoia (jeremyhu) pushed a commit to branch master
> in repository macports-base.
> 
> https://github.com/macports/macports-base/commit/ef5ecfee6f4324e1b76109e01dd96184221d312f
>  
> commit ef5ecfee6f4324e1b76109e01dd96184221d312f
> Author: Jeremy Huddleston Sequoia 
> AuthorDate: Mon Jul 3 20:59:33 2017 -0700
> 
> portconfigure: Put a space between -isysroot and the path
> 
> This is the preferred/supported CLI (per --help)
> 
Can we revert this, please? I deliberately removed the space because using a 
space is not supported by older toolchains.

https://github.com/macports/macports-base/commit/1ab0620c874646646ef4e123a07d38d1452eb6a8

> Signed-off-by: Jeremy Huddleston Sequoia 
> ---
>  src/port1.0/portconfigure.tcl | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/port1.0/portconfigure.tcl b/src/port1.0/portconfigure.tcl
> index 1aac5a8..fa21ead 100644
> --- a/src/port1.0/portconfigure.tcl
> +++ b/src/port1.0/portconfigure.tcl
> @@ -814,7 +814,7 @@ proc portconfigure::configure_main {args} {
>  # add SDK flags if cross-compiling (or universal on ppc tiger)
>  if {${configure.sdkroot} ne ""} {
>  foreach env_var {CPPFLAGS CFLAGS CXXFLAGS OBJCFLAGS OBJCXXFLAGS} 
> {
> -append_to_environment_value configure $env_var 
> -isysroot${configure.sdkroot}
> +append_to_environment_value configure $env_var -isysroot 
> ${configure.sdkroot}
>  }
>  append_to_environment_value configure "LDFLAGS" 
> -Wl,-syslibroot,${configure.sdkroot}
>  }
>