Re: Ports with hardcoded "gcc", "g++"

2017-03-08 Thread Christian Weisgerber
Updated list, 2017-03-08:

lang/jruby
lang/nim
x11/p5-Wx

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



Re: Ports with hardcoded "gcc", "g++"

2017-03-05 Thread Christian Weisgerber
Updated list, 2017-03-05:

devel/boost
java/jna
lang/jruby
lang/nim
net/pidgin
x11/p5-Wx

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



Re: Ports with hardcoded "gcc", "g++"

2017-03-04 Thread Christian Weisgerber
Updated list, 2017-03-04:

devel/boost
devel/jdk/1.7
emulators/virtualjaguar
graphics/ipe
lang/nim
misc/rocrail
net/pidgin
productivity/wyrd
x11/p5-Wx

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



Re: Ports with hardcoded "gcc", "g++"

2017-03-03 Thread Aaron Bieber
On Thu, Mar 02, 2017 at 01:11:05PM +, Christian Weisgerber wrote:
> Updated list:
> 
> archivers/hs-zlib   Matthias Kilian 
> databases/hs-postgresql-libpq David Schaefer 
> devel/boost Brad Smith 
> devel/cil   The OpenBSD ports mailing-list 
> devel/hs-bytestring-mmap Matthias Kilian 
> devel/hs-hinotify   The OpenBSD ports mailing-list 
> devel/hs-lifted-baseMatthias Kilian 
> devel/hs-networkMatthias Kilian 
> devel/hs-old-time   Matthias Kilian 
> devel/hs-primitive  Jim Razmus II 
> devel/hs-readline   Matthias Kilian 
> devel/hs-regex-posixMatthias Kilian 
> devel/hs-unix-compatJim Razmus II 
> devel/jdk/1.7   Kurt Miller 
> devel/ocaml-curses  The OpenBSD ports mailing-list 
> devel/py-sipThe OpenBSD ports mailing-list 
> devel/radare2/main  Edd Barrett 
> games/ioquake3  Aaron Bieber 

Fix committed for ioquake3!

> games/tome4 Solene Rapenne 
> games/wordwarvi Pascal Stumpf 
> graphics/birdfont   Jasper Lievisse Adriaanse 
> graphics/hs-OpenGLRaw   Matthias Kilian 
> lang/nimThe OpenBSD ports mailing-list 
> lang/squeak/vm  Marc Espie 
> misc/rocrailSebastian Reitenbach 
> net/clogThe OpenBSD ports mailing-list 
> net/hs-curl David Schaefer 
> net/hs-network-info David Schaefer 
> net/olsrd   Martin Reindl 
> net/pidgin  Brad Smith 
> productivity/wyrd   Okan Demirmen 
> security/hs-skein   The OpenBSD ports mailing-list 
> textproc/hs-libxml-sax  David Coppa 
> textproc/pilot_makedoc  The OpenBSD ports mailing-list 
> www/phantomjs   Francisco de Borja Lopez Rio 
> x11/hs-X11  Matthias Kilian 
> x11/p5-Wx   The OpenBSD ports mailing-list 
> x11/qt3 Marc Espie 
> x11/qt4 Marc Espie 
> 
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de
> 

-- 
PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A  4AF0 1F81 112D 62A9 ADCE



Re: Ports with hardcoded "gcc", "g++"

2017-03-03 Thread Jeremie Courreges-Anglas
Solène Rapenne  writes:

> Le 2017-02-26 16:00, Christian Weisgerber a écrit :
>> Here is a first batch of ports that fail to build without "gcc" or
>> "g++" being present.  More will come to light eventually.  At the
>> moment, failing dependencies prevent about a third of the ports
>> tree from being built.
>>
>> devel/premake4
>
> hello
>
> I see that devel/premake4 has been fixed.
>
> Sadly, premake4 has gcc hardcoded when invocated. premake5
> seems to have a way to choose between gcc or clang but that's still
> not honoring CC variable and I'm not sure that current port
> (games/tome4) needing premake4 builds with premake5.

Yeah, premake could be patched to stop hardcoding gcc, and perhaps also
to respect CC.

I've fixed the few hardcoded gcc calls that prevented tome4 to build,
however tome4 still uses gcc at build time, this is possible due to the
symlinks set up by the gcc4 module.  I have added a comment about this.

  # The build system hardcodes the use of the "gcc" command
  MODULES = gcc4
  MODGCC4_ARCHS =   *

BTW, is a recent gcc actually required to build this?  tome4 seems to
build fine with /usr/bin/gcc from base.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: ghc.port.mk (was: Ports with hardcoded "gcc", "g++")

2017-03-03 Thread Marc Espie
On Thu, Mar 02, 2017 at 10:03:29PM +0100, Karel Gardas wrote:
> On Thu, Mar 2, 2017 at 9:23 PM, Matthias Kilian  
> wrote:
> > Also, I've no idea wether --with-clang=${CC} will work after the
> > switch to clang. On the other hand, the diff is just a workaround,
> 
> > +MODGHC_SETUP_CONF_ARGS +=  --with-gcc=${CC} --with-clang=${CC}
> 
> 
> Hi Kili,
> 
> I'm curious why this is there at all, I mean --with-clang=${CC} -- if
> I understand policy, then i386/amd64 are not going to be migrated to
> clang anytime soon and clang is default only for arm64 (new port which
> is not supported by in tree gcc) where ghc does not exist yet. So my
> curiosity and question why to bother with it at all?

We're just shaking the ports tree, seeing what bugs fall out.

Seriously, removing all traces of unjustified hardcoded gccs is good.

There are probably going to still be ports where things may want to know.

In any case, having configury that explicitly says "hey this is not called
gcc, so it's not gcc" is... simple-minded.

That's just your usual ports tree stuff: a sweep of 9000+ ports, weeding
out the trivial stuff, so that we can actually spend a few hours on the
remaining stuff.

Cabal is somewhat annoying, because it takes out a large portion of 
the tree, so it's somewhat important to take care of it.

So does boost, for that matter...



Re: ghc.port.mk (was: Ports with hardcoded "gcc", "g++")

2017-03-03 Thread David Coppa
On Thu, Mar 2, 2017 at 11:35 PM, Matthias Kilian  wrote:
> On Thu, Mar 02, 2017 at 09:23:25PM +0100, Matthias Kilian wrote:
>> Running an update bulk build with the diff below now for ghc-7.10.3,
>> to see wether it helps... however, all the hs-ports in my tree are still
>> updated for ghc-8.0.1, so I've no idea wether I'll see anything useful.
>>
>> Also, I've no idea wether --with-clang=${CC} will work after the
>> switch to clang.
>
> Sigh... cabal ports don't't support --with-clang (in contrast to
> ghc, if I didn't misread its configure and build magic). New diff
> below (and I've already failures from pkg_create, which is a *good*
> sign, because it means my (ahead of head) hs-ports at least don't
> fail to build).
>
>
> Index: ghc.port.mk
> ===
> RCS file: /cvs/ports/lang/ghc/ghc.port.mk,v
> retrieving revision 1.38
> diff -u -p -r1.38 ghc.port.mk
> --- ghc.port.mk 20 Jan 2016 16:08:29 -  1.38
> +++ ghc.port.mk 2 Mar 2017 22:23:03 -
> @@ -56,7 +56,7 @@ DIST_SUBDIR ?=ghc
>  . if ${MODGHC_BUILD:L:Mcabal}
>  MODGHC_SETUP_SCRIPT ?= Setup.lhs Setup.hs
>  MODGHC_SETUP_PROG ?=   ${WRKSRC}/Setup
> -MODGHC_SETUP_CONF_ARGS ?=
> +MODGHC_SETUP_CONF_ARGS +=  --with-gcc=${CC}
>  MODGHC_SETUP_CONF_ENV ?=
>
>  .  if !${MODGHC_BUILD:L:Mnort}
>

ok dcoppa@

Ciao!
David



Re: Ports with hardcoded "gcc", "g++"

2017-03-02 Thread Juan Francisco Cantero Hurtado
On Thu, Mar 02, 2017 at 08:44:39PM +0100, Christian Weisgerber wrote:
> Juan Francisco Cantero Hurtado:
> 
> > > ===>  Building for nim-0.16.0p0
> > > cd /usr/obj/nim-0.16.0/nim-0.16.0 && /usr/bin/env -i CC="gcc" 
> > > LINKER="gcc"  CFLA
> > > GS="-O2 -pipe  " sh build.sh
> > > gcc -O2 -pipe -w -fno-strict-aliasing -Ic_code -c 
> > > c_code/3_2/compiler_nim.c -o c
> > > _code/3_2/compiler_nim.o
> > > build.sh[7343]: gcc: not found
> > > *** Error 127 in . (Makefile:36 'do-build')
> > 
> > Add amd64 to CLANG_ARCHS in arch-defines.mk and the port will build
> > fine.
> 
> Why should I do that?
> It isn't supposed to call "gcc" on gcc archs either!

Sorry but I don't have more ideas. I've been trying to create a patch
without to "hardcode" a compiler this afternoon and I failed.

Even if someone makes a patch to honor CC, it would break nim for clang
architectures. If you remove the "gcc" commands from nim to honor CC
during the build on every architecture, then the clang architectures
would have a nim compiler which calls clang when you use "nim c
-cc:gcc".  That's why I used the CLANG_ARCHS conditional and the "-cc"
option in the previous patch.

We also can remove the nim port and to wait until someone steps up as
maintainer :)

-- 
Juan Francisco Cantero Hurtado http://juanfra.info



Re: ghc.port.mk (was: Ports with hardcoded "gcc", "g++")

2017-03-02 Thread Matthias Kilian
On Thu, Mar 02, 2017 at 09:23:25PM +0100, Matthias Kilian wrote:
> Running an update bulk build with the diff below now for ghc-7.10.3,
> to see wether it helps... however, all the hs-ports in my tree are still
> updated for ghc-8.0.1, so I've no idea wether I'll see anything useful.
> 
> Also, I've no idea wether --with-clang=${CC} will work after the
> switch to clang.

Sigh... cabal ports don't't support --with-clang (in contrast to
ghc, if I didn't misread its configure and build magic). New diff
below (and I've already failures from pkg_create, which is a *good*
sign, because it means my (ahead of head) hs-ports at least don't
fail to build).


Index: ghc.port.mk
===
RCS file: /cvs/ports/lang/ghc/ghc.port.mk,v
retrieving revision 1.38
diff -u -p -r1.38 ghc.port.mk
--- ghc.port.mk 20 Jan 2016 16:08:29 -  1.38
+++ ghc.port.mk 2 Mar 2017 22:23:03 -
@@ -56,7 +56,7 @@ DIST_SUBDIR ?=ghc
 . if ${MODGHC_BUILD:L:Mcabal}
 MODGHC_SETUP_SCRIPT ?= Setup.lhs Setup.hs
 MODGHC_SETUP_PROG ?=   ${WRKSRC}/Setup
-MODGHC_SETUP_CONF_ARGS ?=
+MODGHC_SETUP_CONF_ARGS +=  --with-gcc=${CC}
 MODGHC_SETUP_CONF_ENV ?=
 
 .  if !${MODGHC_BUILD:L:Mnort}



Re: ghc.port.mk (was: Ports with hardcoded "gcc", "g++")

2017-03-02 Thread Stuart Henderson
On 2017/03/02 22:03, Karel Gardas wrote:
> On Thu, Mar 2, 2017 at 9:23 PM, Matthias Kilian  
> wrote:
> > Also, I've no idea wether --with-clang=${CC} will work after the
> > switch to clang. On the other hand, the diff is just a workaround,
> 
> > +MODGHC_SETUP_CONF_ARGS +=  --with-gcc=${CC} --with-clang=${CC}
> 
> 
> Hi Kili,
> 
> I'm curious why this is there at all, I mean --with-clang=${CC} -- if
> I understand policy, then i386/amd64 are not going to be migrated to
> clang anytime soon and clang is default only for arm64 (new port which
> is not supported by in tree gcc) where ghc does not exist yet. So my
> curiosity and question why to bother with it at all?

One of the prerequisites for switching other architectures is that it
won't cause too much damage to the ports tree..



Re: ghc.port.mk (was: Ports with hardcoded "gcc", "g++")

2017-03-02 Thread Karel Gardas
On Thu, Mar 2, 2017 at 9:23 PM, Matthias Kilian  wrote:
> Also, I've no idea wether --with-clang=${CC} will work after the
> switch to clang. On the other hand, the diff is just a workaround,

> +MODGHC_SETUP_CONF_ARGS +=  --with-gcc=${CC} --with-clang=${CC}


Hi Kili,

I'm curious why this is there at all, I mean --with-clang=${CC} -- if
I understand policy, then i386/amd64 are not going to be migrated to
clang anytime soon and clang is default only for arm64 (new port which
is not supported by in tree gcc) where ghc does not exist yet. So my
curiosity and question why to bother with it at all?

Thanks,
Karel



ghc.port.mk (was: Ports with hardcoded "gcc", "g++")

2017-03-02 Thread Matthias Kilian
Hi,

On Thu, Mar 02, 2017 at 01:11:05PM +, Christian Weisgerber wrote:
> Updated list:
> 
> archivers/hs-zlib   Matthias Kilian 
> databases/hs-postgresql-libpq David Schaefer 
[...]

Running an update bulk build with the diff below now for ghc-7.10.3,
to see wether it helps... however, all the hs-ports in my tree are still
updated for ghc-8.0.1, so I've no idea wether I'll see anything useful.

Also, I've no idea wether --with-clang=${CC} will work after the
switch to clang. On the other hand, the diff is just a workaround,
the real problem are wrong checks in configure scripts and bugs/thinkos
in the ssource code of libraries/Cabal.

Ciao,
Kili

Index: ghc.port.mk
===
RCS file: /cvs/ports/lang/ghc/ghc.port.mk,v
retrieving revision 1.38
diff -u -p -r1.38 ghc.port.mk
--- ghc.port.mk 20 Jan 2016 16:08:29 -  1.38
+++ ghc.port.mk 2 Mar 2017 20:16:25 -
@@ -56,7 +56,7 @@ DIST_SUBDIR ?=ghc
 . if ${MODGHC_BUILD:L:Mcabal}
 MODGHC_SETUP_SCRIPT ?= Setup.lhs Setup.hs
 MODGHC_SETUP_PROG ?=   ${WRKSRC}/Setup
-MODGHC_SETUP_CONF_ARGS ?=
+MODGHC_SETUP_CONF_ARGS +=  --with-gcc=${CC} --with-clang=${CC}
 MODGHC_SETUP_CONF_ENV ?=
 
 .  if !${MODGHC_BUILD:L:Mnort}



Re: Ports with hardcoded "gcc", "g++"

2017-03-02 Thread Christian Weisgerber
Juan Francisco Cantero Hurtado:

> > ===>  Building for nim-0.16.0p0
> > cd /usr/obj/nim-0.16.0/nim-0.16.0 && /usr/bin/env -i CC="gcc" LINKER="gcc"  
> > CFLA
> > GS="-O2 -pipe  " sh build.sh
> > gcc -O2 -pipe -w -fno-strict-aliasing -Ic_code -c c_code/3_2/compiler_nim.c 
> > -o c
> > _code/3_2/compiler_nim.o
> > build.sh[7343]: gcc: not found
> > *** Error 127 in . (Makefile:36 'do-build')
> 
> Add amd64 to CLANG_ARCHS in arch-defines.mk and the port will build
> fine.

Why should I do that?
It isn't supposed to call "gcc" on gcc archs either!

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



Re: Ports with hardcoded "gcc", "g++"

2017-03-02 Thread Juan Francisco Cantero Hurtado
On Thu, Mar 02, 2017 at 04:33:40PM +0100, Christian Weisgerber wrote:
> Juan Francisco Cantero Hurtado:
> 
> > > I changed the variable to NIM_CC. OK?
> > 
> > And now with "elif" -> "else" fixed.
> 
> There is still confusion about CC and NIM_CC:
> 
> ===>  Building for nim-0.16.0p0
> cd /usr/obj/nim-0.16.0/nim-0.16.0 && /usr/bin/env -i CC="gcc" LINKER="gcc"  
> CFLA
> GS="-O2 -pipe  " sh build.sh
> gcc -O2 -pipe -w -fno-strict-aliasing -Ic_code -c c_code/3_2/compiler_nim.c 
> -o c
> _code/3_2/compiler_nim.o
> build.sh[7343]: gcc: not found
> *** Error 127 in . (Makefile:36 'do-build')

Add amd64 to CLANG_ARCHS in arch-defines.mk and the port will build
fine.

-- 
Juan Francisco Cantero Hurtado http://juanfra.info



Re: Ports with hardcoded "gcc", "g++"

2017-03-02 Thread Solène Rapenne

Le 2017-02-26 16:00, Christian Weisgerber a écrit :

Here is a first batch of ports that fail to build without "gcc" or
"g++" being present.  More will come to light eventually.  At the
moment, failing dependencies prevent about a third of the ports
tree from being built.

devel/premake4


hello

I see that devel/premake4 has been fixed.

Sadly, premake4 has gcc hardcoded when invocated. premake5
seems to have a way to choose between gcc or clang but that's still
not honoring CC variable and I'm not sure that current port
(games/tome4) needing premake4 builds with premake5.

regards



Re: Ports with hardcoded "gcc", "g++"

2017-03-02 Thread Christian Weisgerber
Juan Francisco Cantero Hurtado:

> > I changed the variable to NIM_CC. OK?
> 
> And now with "elif" -> "else" fixed.

There is still confusion about CC and NIM_CC:

===>  Building for nim-0.16.0p0
cd /usr/obj/nim-0.16.0/nim-0.16.0 && /usr/bin/env -i CC="gcc" LINKER="gcc"  CFLA
GS="-O2 -pipe  " sh build.sh
gcc -O2 -pipe -w -fno-strict-aliasing -Ic_code -c c_code/3_2/compiler_nim.c -o c
_code/3_2/compiler_nim.o
build.sh[7343]: gcc: not found
*** Error 127 in . (Makefile:36 'do-build')

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



Re: Ports with hardcoded "gcc", "g++"

2017-03-02 Thread Christian Weisgerber
Updated list:

archivers/hs-zlib   Matthias Kilian 
databases/hs-postgresql-libpq David Schaefer 
devel/boost Brad Smith 
devel/cil   The OpenBSD ports mailing-list 
devel/hs-bytestring-mmap Matthias Kilian 
devel/hs-hinotify   The OpenBSD ports mailing-list 
devel/hs-lifted-baseMatthias Kilian 
devel/hs-networkMatthias Kilian 
devel/hs-old-time   Matthias Kilian 
devel/hs-primitive  Jim Razmus II 
devel/hs-readline   Matthias Kilian 
devel/hs-regex-posixMatthias Kilian 
devel/hs-unix-compatJim Razmus II 
devel/jdk/1.7   Kurt Miller 
devel/ocaml-curses  The OpenBSD ports mailing-list 
devel/py-sipThe OpenBSD ports mailing-list 
devel/radare2/main  Edd Barrett 
games/ioquake3  Aaron Bieber 
games/tome4 Solene Rapenne 
games/wordwarvi Pascal Stumpf 
graphics/birdfont   Jasper Lievisse Adriaanse 
graphics/hs-OpenGLRaw   Matthias Kilian 
lang/nimThe OpenBSD ports mailing-list 
lang/squeak/vm  Marc Espie 
misc/rocrailSebastian Reitenbach 
net/clogThe OpenBSD ports mailing-list 
net/hs-curl David Schaefer 
net/hs-network-info David Schaefer 
net/olsrd   Martin Reindl 
net/pidgin  Brad Smith 
productivity/wyrd   Okan Demirmen 
security/hs-skein   The OpenBSD ports mailing-list 
textproc/hs-libxml-sax  David Coppa 
textproc/pilot_makedoc  The OpenBSD ports mailing-list 
www/phantomjs   Francisco de Borja Lopez Rio 
x11/hs-X11  Matthias Kilian 
x11/p5-Wx   The OpenBSD ports mailing-list 
x11/qt3 Marc Espie 
x11/qt4 Marc Espie 

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



Re: Ports with hardcoded "gcc", "g++"

2017-03-01 Thread Juan Francisco Cantero Hurtado
On Thu, Mar 02, 2017 at 12:46:58AM +0100, Juan Francisco Cantero Hurtado wrote:
> On Wed, Mar 01, 2017 at 11:36:52PM +0100, Juan Francisco Cantero Hurtado 
> wrote:
> > On Wed, Mar 01, 2017 at 11:09:03PM +0100, Christian Weisgerber wrote:
> > > Juan Francisco Cantero Hurtado:
> > > 
> > > > They have a simple option to change the compilers but we need a variable
> > > > with the realname of the compiler, i.e. clang or gcc.
> > > > 
> > > > You can use "nim c -cc:clang" or "nim c -cc:gcc" (the default) or "nim c
> > > > -cc:egcc". All of them are the name of the profile, not the compiler
> > > > executable.
> > > > 
> > > > Here is the patch. It includes some adittional changes. If someone has
> > > > an better idea for the conditional... I'm listening :)
> > > 
> > > CLANG_ARCHS was added incompletely, so you need arch-defines.mk
> > > r1.32 for that:
> > > 
> > > .include 
> > > 
> > > # CC is always "cc". We need the real name.
> > > .if ${PROPERTIES:Mclang}
> > > CC = clang
> > > .else
> > > CC = gcc
> > > .endif
> > > 
> > > BTW, I think using CC for a variable with different semantics is a
> > > bad idea.  Pick a different name, please.
> > 
> > Thanks. How about "COMPILER" or "C_COMP"?
> 
> I changed the variable to NIM_CC. OK?

And now with "elif" -> "else" fixed.


Index: Makefile
===
RCS file: /cvs/ports/lang/nim/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile9 Jan 2017 10:32:33 -   1.6
+++ Makefile1 Mar 2017 23:41:07 -
@@ -5,6 +5,7 @@ ONLY_FOR_ARCHS =i386 amd64
 COMMENT =  statically typed, imperative programming language
 
 VERSION =  0.16.0
+REVISION = 0
 DISTNAME = nim-${VERSION}
 EXTRACT_SUFX = .tar.xz
 
@@ -19,23 +20,28 @@ PERMIT_PACKAGE_CDROM =  Yes
 
 WANTLIB =  c m
 
+SUBST_VARS +=  NIM_CC
+
 post-patch:
mkdir -p ${WRKSRC}/nimcache-port
mkdir -p ${WRKSRC}/nimcache-port-test
perl -i -pe "s#NIM_PORT_PATH#${PATH}#" ${WRKSRC}/koch.nim
perl -i -pe "s#NIM_PORT_CACHE#${WRKSRC}/nimcache-port-test#" \
${WRKSRC}/koch.nim
+   ${SUBST_CMD} ${WRKSRC}/koch.nim ${WRKSRC}/tests/testament/tester.nim \
+   ${WRKSRC}/config/nim.cfg
 
 do-build:
-   cd ${WRKSRC} && ${SETENV} CC="${CC}" LINKER="${CC}" \
+   cd ${WRKSRC} && ${SETENV} CC="${NIM_CC}" LINKER="${NIM_CC}" \
CFLAGS="${CFLAGS}" sh build.sh
# slow machines can get a head of themselves and fail to link
-   cd ${WRKSRC} && bin/nim c -d:release --parallelBuild:1 \
-   --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths \
-   --listCmd --putenv:"PATH=${PATH}" koch
-   cd ${WRKSRC} && ./koch boot -d:release --parallelBuild:1 \
-   --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths \
-   --listCmd --putenv:"PATH=${PATH}"
+   cd ${WRKSRC} && bin/nim c -d:release --cc:${NIM_CC} --parallelBuild:1 \
+   --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths --listCmd \
+   --putenv:"PATH=${PATH} CC=${NIM_CC} LINKER=${NIM_CC}" \
+   koch
+   cd ${WRKSRC} && ./koch boot -d:release --cc:${NIM_CC} --parallelBuild:1 
\
+   --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths --listCmd \
+   --putenv:"PATH=${PATH} CC=${NIM_CC} LINKER=${NIM_CC}"
 
 do-install:
${INSTALL_PROGRAM_DIR} ${PREFIX}/bin
@@ -49,9 +55,17 @@ do-install:
${INSTALL_DATA} ${WRKSRC}/config/*.cfg ${PREFIX}/share/examples/nim
 
 do-test:
-   cd ${WRKSRC} && ${SETENV} ./koch test all -d:release \
-   --parallelBuild:1 --listFullPaths --listCmd \
-   --nimcache:"${WRKSRC}/nimcache-port-test" \
-   --putenv:"PATH=${PATH}"
+   cd ${WRKSRC} && ${SETENV} ./koch test all -d:release --threads:on \
+   --cc:${NIM_CC} --parallelBuild:1 --listFullPaths --listCmd \
+   --passL:"-pthread 
-Wl,-rpath=.:/usr/local/lib:${WRKSRC}/nimcache-port-test/" \
+   --putenv:"PATH=${PATH} CC=${NIM_CC} LINKER=${NIM_CC}"
+
+.include 
+
+.if ${PROPERTIES:Mclang}
+NIM_CC = clang
+.else
+NIM_CC = gcc
+.endif
 
 .include 
Index: patches/patch-config_nim_cfg
===
RCS file: /cvs/ports/lang/nim/patches/patch-config_nim_cfg,v
retrieving revision 1.3
diff -u -p -r1.3 patch-config_nim_cfg
--- patches/patch-config_nim_cfg9 Jan 2017 10:32:33 -   1.3
+++ patches/patch-config_nim_cfg1 Mar 2017 23:41:07 -
@@ -1,6 +1,15 @@
 $OpenBSD: patch-config_nim_cfg,v 1.3 2017/01/09 10:32:33 juanfra Exp $
 --- config/nim.cfg.origSun Jan  8 21:33:42 2017
-+++ config/nim.cfg Mon Jan  9 02:28:32 2017
 config/nim.cfg Wed Mar  1 00:00:37 2017
+@@ -8,7 +8,7 @@
+ # Environment variables can be accessed like so:
+ #  

Re: Ports with hardcoded "gcc", "g++"

2017-03-01 Thread Juan Francisco Cantero Hurtado
On Wed, Mar 01, 2017 at 11:36:52PM +0100, Juan Francisco Cantero Hurtado wrote:
> On Wed, Mar 01, 2017 at 11:09:03PM +0100, Christian Weisgerber wrote:
> > Juan Francisco Cantero Hurtado:
> > 
> > > They have a simple option to change the compilers but we need a variable
> > > with the realname of the compiler, i.e. clang or gcc.
> > > 
> > > You can use "nim c -cc:clang" or "nim c -cc:gcc" (the default) or "nim c
> > > -cc:egcc". All of them are the name of the profile, not the compiler
> > > executable.
> > > 
> > > Here is the patch. It includes some adittional changes. If someone has
> > > an better idea for the conditional... I'm listening :)
> > 
> > CLANG_ARCHS was added incompletely, so you need arch-defines.mk
> > r1.32 for that:
> > 
> > .include 
> > 
> > # CC is always "cc". We need the real name.
> > .if ${PROPERTIES:Mclang}
> > CC = clang
> > .else
> > CC = gcc
> > .endif
> > 
> > BTW, I think using CC for a variable with different semantics is a
> > bad idea.  Pick a different name, please.
> 
> Thanks. How about "COMPILER" or "C_COMP"?

I changed the variable to NIM_CC. OK?


Index: Makefile
===
RCS file: /cvs/ports/lang/nim/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile9 Jan 2017 10:32:33 -   1.6
+++ Makefile1 Mar 2017 23:41:07 -
@@ -5,6 +5,7 @@ ONLY_FOR_ARCHS =i386 amd64
 COMMENT =  statically typed, imperative programming language
 
 VERSION =  0.16.0
+REVISION = 0
 DISTNAME = nim-${VERSION}
 EXTRACT_SUFX = .tar.xz
 
@@ -19,23 +20,28 @@ PERMIT_PACKAGE_CDROM =  Yes
 
 WANTLIB =  c m
 
+SUBST_VARS +=  NIM_CC
+
 post-patch:
mkdir -p ${WRKSRC}/nimcache-port
mkdir -p ${WRKSRC}/nimcache-port-test
perl -i -pe "s#NIM_PORT_PATH#${PATH}#" ${WRKSRC}/koch.nim
perl -i -pe "s#NIM_PORT_CACHE#${WRKSRC}/nimcache-port-test#" \
${WRKSRC}/koch.nim
+   ${SUBST_CMD} ${WRKSRC}/koch.nim ${WRKSRC}/tests/testament/tester.nim \
+   ${WRKSRC}/config/nim.cfg
 
 do-build:
-   cd ${WRKSRC} && ${SETENV} CC="${CC}" LINKER="${CC}" \
+   cd ${WRKSRC} && ${SETENV} CC="${NIM_CC}" LINKER="${NIM_CC}" \
CFLAGS="${CFLAGS}" sh build.sh
# slow machines can get a head of themselves and fail to link
-   cd ${WRKSRC} && bin/nim c -d:release --parallelBuild:1 \
-   --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths \
-   --listCmd --putenv:"PATH=${PATH}" koch
-   cd ${WRKSRC} && ./koch boot -d:release --parallelBuild:1 \
-   --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths \
-   --listCmd --putenv:"PATH=${PATH}"
+   cd ${WRKSRC} && bin/nim c -d:release --cc:${NIM_CC} --parallelBuild:1 \
+   --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths --listCmd \
+   --putenv:"PATH=${PATH} CC=${NIM_CC} LINKER=${NIM_CC}" \
+   koch
+   cd ${WRKSRC} && ./koch boot -d:release --cc:${NIM_CC} --parallelBuild:1 
\
+   --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths --listCmd \
+   --putenv:"PATH=${PATH} CC=${NIM_CC} LINKER=${NIM_CC}"
 
 do-install:
${INSTALL_PROGRAM_DIR} ${PREFIX}/bin
@@ -49,9 +55,17 @@ do-install:
${INSTALL_DATA} ${WRKSRC}/config/*.cfg ${PREFIX}/share/examples/nim
 
 do-test:
-   cd ${WRKSRC} && ${SETENV} ./koch test all -d:release \
-   --parallelBuild:1 --listFullPaths --listCmd \
-   --nimcache:"${WRKSRC}/nimcache-port-test" \
-   --putenv:"PATH=${PATH}"
+   cd ${WRKSRC} && ${SETENV} ./koch test all -d:release --threads:on \
+   --cc:${NIM_CC} --parallelBuild:1 --listFullPaths --listCmd \
+   --passL:"-pthread 
-Wl,-rpath=.:/usr/local/lib:${WRKSRC}/nimcache-port-test/" \
+   --putenv:"PATH=${PATH} CC=${NIM_CC} LINKER=${NIM_CC}"
+
+.include 
+
+.if ${PROPERTIES:Mclang}
+NIM_CC = clang
+.elif
+NIM_CC = gcc
+.endif
 
 .include 
Index: patches/patch-config_nim_cfg
===
RCS file: /cvs/ports/lang/nim/patches/patch-config_nim_cfg,v
retrieving revision 1.3
diff -u -p -r1.3 patch-config_nim_cfg
--- patches/patch-config_nim_cfg9 Jan 2017 10:32:33 -   1.3
+++ patches/patch-config_nim_cfg1 Mar 2017 23:41:07 -
@@ -1,6 +1,15 @@
 $OpenBSD: patch-config_nim_cfg,v 1.3 2017/01/09 10:32:33 juanfra Exp $
 --- config/nim.cfg.origSun Jan  8 21:33:42 2017
-+++ config/nim.cfg Mon Jan  9 02:28:32 2017
 config/nim.cfg Wed Mar  1 00:00:37 2017
+@@ -8,7 +8,7 @@
+ # Environment variables can be accessed like so:
+ #  gcc.path %= "$CC_PATH"
+ 
+-cc = gcc
++cc = ${NIM_CC}
+ 
+ # additional options always passed to the compiler:
+ --parallel_build: "0" # 0 to auto-detect number of processors
 @@ -76,7 

Re: Ports with hardcoded "gcc", "g++"

2017-03-01 Thread Juan Francisco Cantero Hurtado
On Wed, Mar 01, 2017 at 11:09:03PM +0100, Christian Weisgerber wrote:
> Juan Francisco Cantero Hurtado:
> 
> > They have a simple option to change the compilers but we need a variable
> > with the realname of the compiler, i.e. clang or gcc.
> > 
> > You can use "nim c -cc:clang" or "nim c -cc:gcc" (the default) or "nim c
> > -cc:egcc". All of them are the name of the profile, not the compiler
> > executable.
> > 
> > Here is the patch. It includes some adittional changes. If someone has
> > an better idea for the conditional... I'm listening :)
> 
> CLANG_ARCHS was added incompletely, so you need arch-defines.mk
> r1.32 for that:
> 
> .include 
> 
> # CC is always "cc". We need the real name.
> .if ${PROPERTIES:Mclang}
> CC = clang
> .else
> CC = gcc
> .endif
> 
> BTW, I think using CC for a variable with different semantics is a
> bad idea.  Pick a different name, please.

Thanks. How about "COMPILER" or "C_COMP"?

-- 
Juan Francisco Cantero Hurtado http://juanfra.info



Re: Ports with hardcoded "gcc", "g++"

2017-03-01 Thread Juan Francisco Cantero Hurtado
On Wed, Mar 01, 2017 at 08:41:17PM +, Stuart Henderson wrote:
> On 2017/03/01 21:15, Juan Francisco Cantero Hurtado wrote:
> > On Wed, Mar 01, 2017 at 05:45:32PM +, Stuart Henderson wrote:
> > > On 2017/03/01 17:10, Juan Francisco Cantero Hurtado wrote:
> > > > On Tue, Feb 28, 2017 at 07:11:48PM +0100, Juan Francisco Cantero 
> > > > Hurtado wrote:
> > > > > On Tue, Feb 28, 2017 at 01:03:38PM +, Christian Weisgerber wrote:
> > > > > > The fixes that have been committed have unlocked additional parts
> > > > > > of the ports tree, revealing new build failures.  Here is an updated
> > > > > > list.  I've added the MAINTAINERs.
> > > > > > 
> > > > > > lang/nimThe OpenBSD ports mailing-list 
> > > > > > 
> > > > > 
> > > > > I've a patch for nim from two or three days ago. It builds the package
> > > > > but I don't find where is the gcc command in the tests and I don't 
> > > > > want
> > > > > commit the changes without to run first the tests.
> > > > 
> > > > Everything is working now but I need help with something. Nim uses a
> > > > kind of compiler profiles, so we can't just add "${CC}" to the build, we
> > > > need to define the real compiler, i.e. gcc, egcc or clang. Now I'm using
> > > > an if/else conditional with MACHINE_ARCH to define the compiler but I
> > > > would like to use something like "if CLANG_ARCHS contains
> > > > MACHINE_ARCH...". I don't know how to write that. Any idea?.
> > > > 
> > > > -- 
> > > > Juan Francisco Cantero Hurtado http://juanfra.info
> > > > 
> > > 
> > > Ports should honour CC/CXX. Can you sed these into wherever the
> > > compiler profile is defined?
> > 
> > No, because ${CC} is always "cc", not "gcc" or "clang".
> 
> ${CC} is not always "cc", it can be set to something else. For example
> if I do "scan-build make", it is /usr/local/bin/../libexec/ccc-analyzer.
> It might be something else if I want to use distcc, etc.

I know. I meant "by default". I used "make CC=clang" to work in the port.

Anyway, I need a final solution for the port. If people wants to use
"mycompiler" to build nim, then they can create a new entry for the
compiler in the nim config and to run make with "CC=mycompiler". e.g.
jturner@ added the entry for "egcc" long time ago.

Meanwhile, I could commit the port with the conditional commented:

#.if ${MACHINE_ARCH} == "amd64"
#CC = clang
#.elif
CC = gcc
#.endif

With the changes, "CC=cc" will not work anymore. In fact, nim never used
"cc" as its compiler.

-- 
Juan Francisco Cantero Hurtado http://juanfra.info



Re: Ports with hardcoded "gcc", "g++"

2017-03-01 Thread Christian Weisgerber
Juan Francisco Cantero Hurtado:

> They have a simple option to change the compilers but we need a variable
> with the realname of the compiler, i.e. clang or gcc.
> 
> You can use "nim c -cc:clang" or "nim c -cc:gcc" (the default) or "nim c
> -cc:egcc". All of them are the name of the profile, not the compiler
> executable.
> 
> Here is the patch. It includes some adittional changes. If someone has
> an better idea for the conditional... I'm listening :)

CLANG_ARCHS was added incompletely, so you need arch-defines.mk
r1.32 for that:

.include 

# CC is always "cc". We need the real name.
.if ${PROPERTIES:Mclang}
CC = clang
.else
CC = gcc
.endif

BTW, I think using CC for a variable with different semantics is a
bad idea.  Pick a different name, please.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



Re: Ports with hardcoded "gcc", "g++"

2017-03-01 Thread Frank Groeneveld
On Wed, Mar 1, 2017, at 17:47, Amit Kulkarni wrote:
> I meant to say the .a file is missing for libQtWebkit
> 
> Thanks
> 

Found the cause and fixed it. Attached patch makes it build correctly
without g++/gcc.

Thanks again Stuart and Amit for the hints.

Frank
Index: Makefile
===
RCS file: /cvs/ports/textproc/wkhtmltopdf/Makefile,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile
--- Makefile	13 Sep 2016 18:52:06 -	1.12
+++ Makefile	1 Mar 2017 20:06:14 -
@@ -39,7 +39,9 @@ LIB_DEPENDS =		converters/libiconv \
 
 USE_GMAKE =		Yes
 MAKE_FLAGS =		LIBwkhtmltox_VERSION=${LIBwkhtmltox_VERSION}
-MAKE_ENV +=		WRKBUILD=${WRKBUILD}
+MAKE_ENV +=		WRKBUILD=${WRKBUILD} \
+			PORTS_CC="${CC}" PORTS_CXX="${CXX}"
+CONFIGURE_ENV =	PORTS_CC="${CC}" PORTS_CXX="${CXX}"
 FAKE_FLAGS =		INSTALL_ROOT=${WRKINST}${TRUEPREFIX}
 
 SEPARATE_BUILD =	Yes
@@ -51,7 +53,7 @@ pre-patch:
 	cd ${WRKDIR}/${DISTNAME} && mv ../qt-${QT_COMMIT} qt
 
 do-configure:
-	mkdir ${WRKBUILD}/qt
+	mkdir -p ${WRKBUILD}/qt
 	# qt config options taken from scripts/build.py
 	cd ${WRKBUILD}/qt && \
 		env -i ${CONFIGURE_ENV} ${WRKSRC}/qt/configure \
Index: patches/patch-qt_configure
===
RCS file: patches/patch-qt_configure
diff -N patches/patch-qt_configure
--- /dev/null	1 Jan 1970 00:00:00 -
+++ patches/patch-qt_configure	1 Mar 2017 20:06:14 -
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- qt/configure.orig	Wed Mar  1 20:53:04 2017
 qt/configure	Wed Mar  1 20:53:19 2017
+@@ -3411,7 +3411,7 @@ else
+ CFG_FRAMEWORK=no
+ fi
+ 
+-QMAKE_CONF_COMPILER=`getXQMakeConf QMAKE_CXX`
++QMAKE_CONF_COMPILER="${PORTS_CXX}"
+ TEST_COMPILER="$CXX"
+ 
+ [ -z "$TEST_COMPILER" ] && TEST_COMPILER=$QMAKE_CONF_COMPILER
Index: patches/patch-qt_mkspecs_openbsd-g++_qmake_conf
===
RCS file: patches/patch-qt_mkspecs_openbsd-g++_qmake_conf
diff -N patches/patch-qt_mkspecs_openbsd-g++_qmake_conf
--- /dev/null	1 Jan 1970 00:00:00 -
+++ patches/patch-qt_mkspecs_openbsd-g++_qmake_conf	1 Mar 2017 20:06:14 -
@@ -0,0 +1,36 @@
+$OpenBSD$
+--- qt/mkspecs/openbsd-g++/qmake.conf.orig	Tue May 10 09:19:52 2016
 qt/mkspecs/openbsd-g++/qmake.conf	Wed Mar  1 12:07:44 2017
+@@ -8,7 +8,7 @@ TEMPLATE		= app
+ CONFIG			+= qt warn_on release link_prl gdb_dwarf_index
+ QT			+= core gui
+ 
+-QMAKE_CC		= gcc
++QMAKE_CC		= ${PORTS_CC}
+ QMAKE_LEX		= flex
+ QMAKE_LEXFLAGS		=
+ QMAKE_YACC		= yacc
+@@ -24,7 +24,7 @@ QMAKE_CFLAGS_STATIC_LIB	= $$QMAKE_CFLAGS_SHLIB
+ QMAKE_CFLAGS_YACC	= -Wno-unused -Wno-parentheses
+ QMAKE_CFLAGS_THREAD	= -pthread
+ 
+-QMAKE_CXX		= g++
++QMAKE_CXX		= ${PORTS_CXX}
+ QMAKE_CXXFLAGS		= $$QMAKE_CFLAGS
+ QMAKE_CXXFLAGS_DEPS	= $$QMAKE_CFLAGS_DEPS
+ QMAKE_CXXFLAGS_WARN_ON	= $$QMAKE_CFLAGS_WARN_ON
+@@ -45,10 +45,10 @@ QMAKE_LIBDIR_QT		= $$[QT_INSTALL_LIBS]
+ QMAKE_INCDIR_OPENGL	= /usr/X11R6/include
+ QMAKE_LIBDIR_OPENGL	= /usr/X11R6/lib
+ 
+-QMAKE_LINK		= g++
+-QMAKE_LINK_SHLIB	= g++
+-QMAKE_LINK_C		= gcc
+-QMAKE_LINK_C_SHLIB	= gcc
++QMAKE_LINK		= $$QMAKE_CXX
++QMAKE_LINK_SHLIB	= $$QMAKE_CXX
++QMAKE_LINK_C		= $$QMAKE_CC
++QMAKE_LINK_C_SHLIB	= $$QMAKE_CC
+ QMAKE_LINK_SHLIB_CMD	= $$QMAKE_LINK_SHLIB $(LFLAGS) \
+ 	$$QMAKE_CFLAGS_SHLIB $$QMAKE_LFLAGS \
+ 	-o $(TARGETD) $(OBJECTS) $(OBJMOC) $(LIBS)


Re: Ports with hardcoded "gcc", "g++"

2017-03-01 Thread Stuart Henderson
On 2017/03/01 21:15, Juan Francisco Cantero Hurtado wrote:
> On Wed, Mar 01, 2017 at 05:45:32PM +, Stuart Henderson wrote:
> > On 2017/03/01 17:10, Juan Francisco Cantero Hurtado wrote:
> > > On Tue, Feb 28, 2017 at 07:11:48PM +0100, Juan Francisco Cantero Hurtado 
> > > wrote:
> > > > On Tue, Feb 28, 2017 at 01:03:38PM +, Christian Weisgerber wrote:
> > > > > The fixes that have been committed have unlocked additional parts
> > > > > of the ports tree, revealing new build failures.  Here is an updated
> > > > > list.  I've added the MAINTAINERs.
> > > > > 
> > > > > lang/nimThe OpenBSD ports mailing-list 
> > > > 
> > > > I've a patch for nim from two or three days ago. It builds the package
> > > > but I don't find where is the gcc command in the tests and I don't want
> > > > commit the changes without to run first the tests.
> > > 
> > > Everything is working now but I need help with something. Nim uses a
> > > kind of compiler profiles, so we can't just add "${CC}" to the build, we
> > > need to define the real compiler, i.e. gcc, egcc or clang. Now I'm using
> > > an if/else conditional with MACHINE_ARCH to define the compiler but I
> > > would like to use something like "if CLANG_ARCHS contains
> > > MACHINE_ARCH...". I don't know how to write that. Any idea?.
> > > 
> > > -- 
> > > Juan Francisco Cantero Hurtado http://juanfra.info
> > > 
> > 
> > Ports should honour CC/CXX. Can you sed these into wherever the
> > compiler profile is defined?
> 
> No, because ${CC} is always "cc", not "gcc" or "clang".

${CC} is not always "cc", it can be set to something else. For example
if I do "scan-build make", it is /usr/local/bin/../libexec/ccc-analyzer.
It might be something else if I want to use distcc, etc.




Re: Ports with hardcoded "gcc", "g++"

2017-03-01 Thread Juan Francisco Cantero Hurtado
On Wed, Mar 01, 2017 at 05:45:32PM +, Stuart Henderson wrote:
> On 2017/03/01 17:10, Juan Francisco Cantero Hurtado wrote:
> > On Tue, Feb 28, 2017 at 07:11:48PM +0100, Juan Francisco Cantero Hurtado 
> > wrote:
> > > On Tue, Feb 28, 2017 at 01:03:38PM +, Christian Weisgerber wrote:
> > > > The fixes that have been committed have unlocked additional parts
> > > > of the ports tree, revealing new build failures.  Here is an updated
> > > > list.  I've added the MAINTAINERs.
> > > > 
> > > > lang/nimThe OpenBSD ports mailing-list 
> > > 
> > > I've a patch for nim from two or three days ago. It builds the package
> > > but I don't find where is the gcc command in the tests and I don't want
> > > commit the changes without to run first the tests.
> > 
> > Everything is working now but I need help with something. Nim uses a
> > kind of compiler profiles, so we can't just add "${CC}" to the build, we
> > need to define the real compiler, i.e. gcc, egcc or clang. Now I'm using
> > an if/else conditional with MACHINE_ARCH to define the compiler but I
> > would like to use something like "if CLANG_ARCHS contains
> > MACHINE_ARCH...". I don't know how to write that. Any idea?.
> > 
> > -- 
> > Juan Francisco Cantero Hurtado http://juanfra.info
> > 
> 
> Ports should honour CC/CXX. Can you sed these into wherever the
> compiler profile is defined?

No, because ${CC} is always "cc", not "gcc" or "clang".

We can't use a regex blindly to modify nim because it will give us
problems. Patching the code is even worse because the updates will be
harder and nim hasn't a maintainer.

They have a simple option to change the compilers but we need a variable
with the realname of the compiler, i.e. clang or gcc.

You can use "nim c -cc:clang" or "nim c -cc:gcc" (the default) or "nim c
-cc:egcc". All of them are the name of the profile, not the compiler
executable.

Here is the patch. It includes some adittional changes. If someone has
an better idea for the conditional... I'm listening :)


Index: Makefile
===
RCS file: /cvs/ports/lang/nim/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile9 Jan 2017 10:32:33 -   1.6
+++ Makefile1 Mar 2017 19:55:21 -
@@ -5,6 +5,7 @@ ONLY_FOR_ARCHS =i386 amd64
 COMMENT =  statically typed, imperative programming language
 
 VERSION =  0.16.0
+REVISION = 0
 DISTNAME = nim-${VERSION}
 EXTRACT_SUFX = .tar.xz
 
@@ -19,23 +20,28 @@ PERMIT_PACKAGE_CDROM =  Yes
 
 WANTLIB =  c m
 
+SUBST_VARS +=  CC
+
 post-patch:
mkdir -p ${WRKSRC}/nimcache-port
mkdir -p ${WRKSRC}/nimcache-port-test
perl -i -pe "s#NIM_PORT_PATH#${PATH}#" ${WRKSRC}/koch.nim
perl -i -pe "s#NIM_PORT_CACHE#${WRKSRC}/nimcache-port-test#" \
${WRKSRC}/koch.nim
+   ${SUBST_CMD} ${WRKSRC}/koch.nim ${WRKSRC}/tests/testament/tester.nim \
+   ${WRKSRC}/config/nim.cfg
 
 do-build:
cd ${WRKSRC} && ${SETENV} CC="${CC}" LINKER="${CC}" \
CFLAGS="${CFLAGS}" sh build.sh
# slow machines can get a head of themselves and fail to link
-   cd ${WRKSRC} && bin/nim c -d:release --parallelBuild:1 \
-   --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths \
-   --listCmd --putenv:"PATH=${PATH}" koch
-   cd ${WRKSRC} && ./koch boot -d:release --parallelBuild:1 \
-   --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths \
-   --listCmd --putenv:"PATH=${PATH}"
+   cd ${WRKSRC} && bin/nim c -d:release --cc:${CC} --parallelBuild:1 \
+   --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths --listCmd \
+   --putenv:"PATH=${PATH} CC=${CC} LINKER=${CC}" \
+   koch
+   cd ${WRKSRC} && ./koch boot -d:release --cc:${CC} --parallelBuild:1 \
+   --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths --listCmd \
+   --putenv:"PATH=${PATH} CC=${CC} LINKER=${CC}"
 
 do-install:
${INSTALL_PROGRAM_DIR} ${PREFIX}/bin
@@ -49,9 +55,16 @@ do-install:
${INSTALL_DATA} ${WRKSRC}/config/*.cfg ${PREFIX}/share/examples/nim
 
 do-test:
-   cd ${WRKSRC} && ${SETENV} ./koch test all -d:release \
-   --parallelBuild:1 --listFullPaths --listCmd \
-   --nimcache:"${WRKSRC}/nimcache-port-test" \
-   --putenv:"PATH=${PATH}"
+   cd ${WRKSRC} && ${SETENV} ./koch test all -d:release --threads:on \
+   --cc:${CC} --parallelBuild:1 --listFullPaths --listCmd \
+   --passL:"-pthread 
-Wl,-rpath=.:/usr/local/lib:${WRKSRC}/nimcache-port-test/" \
+   --putenv:"PATH=${PATH} CC=${CC} LINKER=${CC}"
+
+# CC is always "cc". We need the real name.
+.if ${MACHINE_ARCH} == "amd64"
+CC = clang
+.elif
+CC = gcc
+.endif
 
 .include 
Index: patches/patch-config_nim_cfg

Re: Ports with hardcoded "gcc", "g++"

2017-03-01 Thread Stuart Henderson
On 2017/03/01 17:10, Juan Francisco Cantero Hurtado wrote:
> On Tue, Feb 28, 2017 at 07:11:48PM +0100, Juan Francisco Cantero Hurtado 
> wrote:
> > On Tue, Feb 28, 2017 at 01:03:38PM +, Christian Weisgerber wrote:
> > > The fixes that have been committed have unlocked additional parts
> > > of the ports tree, revealing new build failures.  Here is an updated
> > > list.  I've added the MAINTAINERs.
> > > 
> > > lang/nimThe OpenBSD ports mailing-list 
> > 
> > I've a patch for nim from two or three days ago. It builds the package
> > but I don't find where is the gcc command in the tests and I don't want
> > commit the changes without to run first the tests.
> 
> Everything is working now but I need help with something. Nim uses a
> kind of compiler profiles, so we can't just add "${CC}" to the build, we
> need to define the real compiler, i.e. gcc, egcc or clang. Now I'm using
> an if/else conditional with MACHINE_ARCH to define the compiler but I
> would like to use something like "if CLANG_ARCHS contains
> MACHINE_ARCH...". I don't know how to write that. Any idea?.
> 
> -- 
> Juan Francisco Cantero Hurtado http://juanfra.info
> 

Ports should honour CC/CXX. Can you sed these into wherever the
compiler profile is defined?



Re: Ports with hardcoded "gcc", "g++"

2017-03-01 Thread Juan Francisco Cantero Hurtado
On Tue, Feb 28, 2017 at 07:11:48PM +0100, Juan Francisco Cantero Hurtado wrote:
> On Tue, Feb 28, 2017 at 01:03:38PM +, Christian Weisgerber wrote:
> > The fixes that have been committed have unlocked additional parts
> > of the ports tree, revealing new build failures.  Here is an updated
> > list.  I've added the MAINTAINERs.
> > 
> > lang/nimThe OpenBSD ports mailing-list 
> 
> I've a patch for nim from two or three days ago. It builds the package
> but I don't find where is the gcc command in the tests and I don't want
> commit the changes without to run first the tests.

Everything is working now but I need help with something. Nim uses a
kind of compiler profiles, so we can't just add "${CC}" to the build, we
need to define the real compiler, i.e. gcc, egcc or clang. Now I'm using
an if/else conditional with MACHINE_ARCH to define the compiler but I
would like to use something like "if CLANG_ARCHS contains
MACHINE_ARCH...". I don't know how to write that. Any idea?.

-- 
Juan Francisco Cantero Hurtado http://juanfra.info



Re: Ports with hardcoded "gcc", "g++"

2017-03-01 Thread Amit Kulkarni
On Wed, Mar 1, 2017 at 10:44 AM, Amit Kulkarni  wrote:
> On Wed, Mar 1, 2017 at 10:10 AM, Frank Groeneveld
>  wrote:
>> On Wed, Mar 1, 2017, at 15:14, Stuart Henderson wrote:
>>> Oops, I forgot to re-run update-patches and had an old one. However
>>> unfortunately
>>> not enough as linking fails.
>>>
>>
>> Thanks, that gets us a lot further indeed. The complete QT build
>> finished and now only the final linking step fails indeed.
>> For the interested, this is the command:
>>
>> c++ -L/usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/lib -pthread
>> -shared -Wl,-soname,libwkhtmltox.so.0 -fPIC -o libwkhtmltox.so.0.0
>> loadsettings.o multipageloader.o tempfile.o converter.o websettings.o
>> reflect.o utilities.o pdfsettings.o pdfconverter.o outline.o
>> tocstylesheet.o imagesettings.o imageconverter.o pdf_c_bindings.o
>> image_c_bindings.o moc_multipageloader_p.o moc_converter_p.o
>> moc_pdfconverter_p.o moc_imageconverter_p.o moc_pdf_c_bindings_p.o
>> moc_image_c_bindings_p.o moc_converter.o moc_multipageloader.o
>> moc_utilities.o moc_pdfconverter.o moc_imageconverter.o
>> qrc_wkhtmltopdf.o-L/usr/local/lib
>> -L/usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/lib
>> -L/usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/plugins/codecs
>> -lqcncodecs -L/usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/lib
>> -L/usr/local/lib -lqjpcodecs -lqkrcodecs -lqtwcodecs -lQtWebKit
>> -L/usr/X11R6/lib -lQtSvg -lQtXmlPatterns -lQtGui -ljpeg -lpng -lXrender
>> -lfontconfig -lfreetype -lXext -lX11 -lQtNetwork -lQtCore -lz -lm
>> -liconv
>> /usr/bin/ld: cannot find -lQtWebKit
>>
>> Which seems weird to me, because:
>>
>> $ ls /usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/lib
>> libQAxContainer.prllibQtNetwork.a libQtSvg.prl
>> libQAxServer.prl   libQtNetwork.lalibQtTest.a
>> libQt3Support.la   libQtNetwork.prl   libQtTest.la
>> libQt3Support.prl  libQtOpenGL.la libQtTest.prl
>> libQtCore.alibQtOpenGL.prllibQtWebKit.la
>> libQtCore.la   libQtOpenVG.la libQtWebKit.prl
>> libQtCore.prl  libQtOpenVG.prllibQtXml.a
>> libQtDBus.la   libQtScript.la libQtXml.la
>> libQtDBus.prl  libQtScript.prllibQtXml.prl
>> libQtDeclarative.lalibQtScriptTools.lalibQtXmlPatterns.a
>> libQtDeclarative.prl   libQtScriptTools.prl
>> libQtXmlPatterns.la
>> libQtGui.a libQtSql.a
>> libQtXmlPatterns.prl
>> libQtGui.lalibQtSql.lalibpvrQWSWSEGL.prl
>> libQtGui.prl   libQtSql.prl   pkgconfig
>> libQtMultimedia.la libQtSvg.a
>> libQtMultimedia.prllibQtSvg.la
>>
>> libQtWebkit seems to be there, right?
>>
>>
>
> libQtWebkit does not seem to be listed in /usr/ports/pobj, but the
> others seem to be listed. I see QtNetwork is listed...

I meant to say the .a file is missing for libQtWebkit

Thanks



Re: Ports with hardcoded "gcc", "g++"

2017-03-01 Thread Amit Kulkarni
On Wed, Mar 1, 2017 at 10:10 AM, Frank Groeneveld
 wrote:
> On Wed, Mar 1, 2017, at 15:14, Stuart Henderson wrote:
>> Oops, I forgot to re-run update-patches and had an old one. However
>> unfortunately
>> not enough as linking fails.
>>
>
> Thanks, that gets us a lot further indeed. The complete QT build
> finished and now only the final linking step fails indeed.
> For the interested, this is the command:
>
> c++ -L/usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/lib -pthread
> -shared -Wl,-soname,libwkhtmltox.so.0 -fPIC -o libwkhtmltox.so.0.0
> loadsettings.o multipageloader.o tempfile.o converter.o websettings.o
> reflect.o utilities.o pdfsettings.o pdfconverter.o outline.o
> tocstylesheet.o imagesettings.o imageconverter.o pdf_c_bindings.o
> image_c_bindings.o moc_multipageloader_p.o moc_converter_p.o
> moc_pdfconverter_p.o moc_imageconverter_p.o moc_pdf_c_bindings_p.o
> moc_image_c_bindings_p.o moc_converter.o moc_multipageloader.o
> moc_utilities.o moc_pdfconverter.o moc_imageconverter.o
> qrc_wkhtmltopdf.o-L/usr/local/lib
> -L/usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/lib
> -L/usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/plugins/codecs
> -lqcncodecs -L/usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/lib
> -L/usr/local/lib -lqjpcodecs -lqkrcodecs -lqtwcodecs -lQtWebKit
> -L/usr/X11R6/lib -lQtSvg -lQtXmlPatterns -lQtGui -ljpeg -lpng -lXrender
> -lfontconfig -lfreetype -lXext -lX11 -lQtNetwork -lQtCore -lz -lm
> -liconv
> /usr/bin/ld: cannot find -lQtWebKit
>
> Which seems weird to me, because:
>
> $ ls /usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/lib
> libQAxContainer.prllibQtNetwork.a libQtSvg.prl
> libQAxServer.prl   libQtNetwork.lalibQtTest.a
> libQt3Support.la   libQtNetwork.prl   libQtTest.la
> libQt3Support.prl  libQtOpenGL.la libQtTest.prl
> libQtCore.alibQtOpenGL.prllibQtWebKit.la
> libQtCore.la   libQtOpenVG.la libQtWebKit.prl
> libQtCore.prl  libQtOpenVG.prllibQtXml.a
> libQtDBus.la   libQtScript.la libQtXml.la
> libQtDBus.prl  libQtScript.prllibQtXml.prl
> libQtDeclarative.lalibQtScriptTools.lalibQtXmlPatterns.a
> libQtDeclarative.prl   libQtScriptTools.prl
> libQtXmlPatterns.la
> libQtGui.a libQtSql.a
> libQtXmlPatterns.prl
> libQtGui.lalibQtSql.lalibpvrQWSWSEGL.prl
> libQtGui.prl   libQtSql.prl   pkgconfig
> libQtMultimedia.la libQtSvg.a
> libQtMultimedia.prllibQtSvg.la
>
> libQtWebkit seems to be there, right?
>
>

libQtWebkit does not seem to be listed in /usr/ports/pobj, but the
others seem to be listed. I see QtNetwork is listed...



Re: Ports with hardcoded "gcc", "g++"

2017-03-01 Thread Frank Groeneveld
On Wed, Mar 1, 2017, at 15:14, Stuart Henderson wrote:
> Oops, I forgot to re-run update-patches and had an old one. However
> unfortunately
> not enough as linking fails.
> 

Thanks, that gets us a lot further indeed. The complete QT build
finished and now only the final linking step fails indeed.
For the interested, this is the command:

c++ -L/usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/lib -pthread
-shared -Wl,-soname,libwkhtmltox.so.0 -fPIC -o libwkhtmltox.so.0.0
loadsettings.o multipageloader.o tempfile.o converter.o websettings.o
reflect.o utilities.o pdfsettings.o pdfconverter.o outline.o
tocstylesheet.o imagesettings.o imageconverter.o pdf_c_bindings.o
image_c_bindings.o moc_multipageloader_p.o moc_converter_p.o
moc_pdfconverter_p.o moc_imageconverter_p.o moc_pdf_c_bindings_p.o
moc_image_c_bindings_p.o moc_converter.o moc_multipageloader.o
moc_utilities.o moc_pdfconverter.o moc_imageconverter.o
qrc_wkhtmltopdf.o-L/usr/local/lib
-L/usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/lib
-L/usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/plugins/codecs
-lqcncodecs -L/usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/lib
-L/usr/local/lib -lqjpcodecs -lqkrcodecs -lqtwcodecs -lQtWebKit
-L/usr/X11R6/lib -lQtSvg -lQtXmlPatterns -lQtGui -ljpeg -lpng -lXrender
-lfontconfig -lfreetype -lXext -lX11 -lQtNetwork -lQtCore -lz -lm
-liconv 
/usr/bin/ld: cannot find -lQtWebKit

Which seems weird to me, because:

$ ls /usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/lib 
libQAxContainer.prllibQtNetwork.a libQtSvg.prl
libQAxServer.prl   libQtNetwork.lalibQtTest.a
libQt3Support.la   libQtNetwork.prl   libQtTest.la
libQt3Support.prl  libQtOpenGL.la libQtTest.prl
libQtCore.alibQtOpenGL.prllibQtWebKit.la
libQtCore.la   libQtOpenVG.la libQtWebKit.prl
libQtCore.prl  libQtOpenVG.prllibQtXml.a
libQtDBus.la   libQtScript.la libQtXml.la
libQtDBus.prl  libQtScript.prllibQtXml.prl
libQtDeclarative.lalibQtScriptTools.lalibQtXmlPatterns.a
libQtDeclarative.prl   libQtScriptTools.prl  
libQtXmlPatterns.la
libQtGui.a libQtSql.a
libQtXmlPatterns.prl
libQtGui.lalibQtSql.lalibpvrQWSWSEGL.prl
libQtGui.prl   libQtSql.prl   pkgconfig
libQtMultimedia.la libQtSvg.a
libQtMultimedia.prllibQtSvg.la

libQtWebkit seems to be there, right?

Frank



Re: Ports with hardcoded "gcc", "g++"

2017-03-01 Thread Stuart Henderson
On 2017/03/01 12:12, Stuart Henderson wrote:
> On 2017/03/01 11:02, Frank Groeneveld wrote:
> > On Tue, Feb 28, 2017, at 14:03, Christian Weisgerber wrote:
> > > textproc/wkhtmltopdf Frank Groeneveld 
> > 
> > I've been trying to fix textporc/wkhtmltopdf in the last few days, but
> > can't seem to make qmake use the correct compiler. The do-configure step
> > of this port configures the patched QT that is part of the port. I've
> > tried adding CXX="${CXX}" and/or SYS_CXX="${CXX}" to the env of that
> > step, but it seems to be unused. Anybody got some hints on how to fix
> > this one?
> > 
> > Thanks!
> > Frank
> > 
> 
> It gets further with this, build is still running so there might be
> more needed.

Oops, I forgot to re-run update-patches and had an old one. However 
unfortunately
not enough as linking fails.

Index: Makefile
===
RCS file: /cvs/ports/textproc/wkhtmltopdf/Makefile,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile
--- Makefile13 Sep 2016 18:52:06 -  1.12
+++ Makefile1 Mar 2017 14:13:39 -
@@ -39,7 +39,9 @@ LIB_DEPENDS = converters/libiconv \
 
 USE_GMAKE =Yes
 MAKE_FLAGS =   LIBwkhtmltox_VERSION=${LIBwkhtmltox_VERSION}
-MAKE_ENV +=WRKBUILD=${WRKBUILD}
+MAKE_ENV +=WRKBUILD=${WRKBUILD} \
+   PORTS_CC="${CC}" PORTS_CXX="${CXX}"
+CONFIGURE_ENV =PORTS_CC="${CC}" PORTS_CXX="${CXX}"
 FAKE_FLAGS =   INSTALL_ROOT=${WRKINST}${TRUEPREFIX}
 
 SEPARATE_BUILD =   Yes
@@ -51,7 +53,7 @@ pre-patch:
cd ${WRKDIR}/${DISTNAME} && mv ../qt-${QT_COMMIT} qt
 
 do-configure:
-   mkdir ${WRKBUILD}/qt
+   mkdir -p ${WRKBUILD}/qt
# qt config options taken from scripts/build.py
cd ${WRKBUILD}/qt && \
env -i ${CONFIGURE_ENV} ${WRKSRC}/qt/configure \
Index: patches/patch-qt_mkspecs_openbsd-g++_qmake_conf
===
RCS file: patches/patch-qt_mkspecs_openbsd-g++_qmake_conf
diff -N patches/patch-qt_mkspecs_openbsd-g++_qmake_conf
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-qt_mkspecs_openbsd-g++_qmake_conf 1 Mar 2017 14:13:39 
-
@@ -0,0 +1,36 @@
+$OpenBSD$
+--- qt/mkspecs/openbsd-g++/qmake.conf.orig Tue May 10 09:19:52 2016
 qt/mkspecs/openbsd-g++/qmake.conf  Wed Mar  1 12:07:44 2017
+@@ -8,7 +8,7 @@ TEMPLATE   = app
+ CONFIG+= qt warn_on release link_prl gdb_dwarf_index
+ QT+= core gui
+ 
+-QMAKE_CC  = gcc
++QMAKE_CC  = ${PORTS_CC}
+ QMAKE_LEX = flex
+ QMAKE_LEXFLAGS=
+ QMAKE_YACC= yacc
+@@ -24,7 +24,7 @@ QMAKE_CFLAGS_STATIC_LIB  = $$QMAKE_CFLAGS_SHLIB
+ QMAKE_CFLAGS_YACC = -Wno-unused -Wno-parentheses
+ QMAKE_CFLAGS_THREAD   = -pthread
+ 
+-QMAKE_CXX = g++
++QMAKE_CXX = ${PORTS_CXX}
+ QMAKE_CXXFLAGS= $$QMAKE_CFLAGS
+ QMAKE_CXXFLAGS_DEPS   = $$QMAKE_CFLAGS_DEPS
+ QMAKE_CXXFLAGS_WARN_ON= $$QMAKE_CFLAGS_WARN_ON
+@@ -45,10 +45,10 @@ QMAKE_LIBDIR_QT= $$[QT_INSTALL_LIBS]
+ QMAKE_INCDIR_OPENGL   = /usr/X11R6/include
+ QMAKE_LIBDIR_OPENGL   = /usr/X11R6/lib
+ 
+-QMAKE_LINK= g++
+-QMAKE_LINK_SHLIB  = g++
+-QMAKE_LINK_C  = gcc
+-QMAKE_LINK_C_SHLIB= gcc
++QMAKE_LINK= $$QMAKE_CXX
++QMAKE_LINK_SHLIB  = $$QMAKE_CXX
++QMAKE_LINK_C  = $$QMAKE_CC
++QMAKE_LINK_C_SHLIB= $$QMAKE_CC
+ QMAKE_LINK_SHLIB_CMD  = $$QMAKE_LINK_SHLIB $(LFLAGS) \
+   $$QMAKE_CFLAGS_SHLIB $$QMAKE_LFLAGS \
+   -o $(TARGETD) $(OBJECTS) $(OBJMOC) $(LIBS)



Re: Ports with hardcoded "gcc", "g++"

2017-03-01 Thread Stuart Henderson
On 2017/03/01 11:02, Frank Groeneveld wrote:
> On Tue, Feb 28, 2017, at 14:03, Christian Weisgerber wrote:
> > textproc/wkhtmltopdf Frank Groeneveld 
> 
> I've been trying to fix textporc/wkhtmltopdf in the last few days, but
> can't seem to make qmake use the correct compiler. The do-configure step
> of this port configures the patched QT that is part of the port. I've
> tried adding CXX="${CXX}" and/or SYS_CXX="${CXX}" to the env of that
> step, but it seems to be unused. Anybody got some hints on how to fix
> this one?
> 
> Thanks!
> Frank
> 

It gets further with this, build is still running so there might be
more needed.

Index: Makefile
===
RCS file: /cvs/ports/textproc/wkhtmltopdf/Makefile,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile
--- Makefile13 Sep 2016 18:52:06 -  1.12
+++ Makefile1 Mar 2017 12:12:09 -
@@ -39,7 +39,9 @@ LIB_DEPENDS = converters/libiconv \
 
 USE_GMAKE =Yes
 MAKE_FLAGS =   LIBwkhtmltox_VERSION=${LIBwkhtmltox_VERSION}
-MAKE_ENV +=WRKBUILD=${WRKBUILD}
+MAKE_ENV +=WRKBUILD=${WRKBUILD} \
+   PORTS_CC="${CC}" PORTS_CXX="${CXX}"
+CONFIGURE_ENV =PORTS_CC="${CC}" PORTS_CXX="${CXX}"
 FAKE_FLAGS =   INSTALL_ROOT=${WRKINST}${TRUEPREFIX}
 
 SEPARATE_BUILD =   Yes
@@ -51,7 +53,7 @@ pre-patch:
cd ${WRKDIR}/${DISTNAME} && mv ../qt-${QT_COMMIT} qt
 
 do-configure:
-   mkdir ${WRKBUILD}/qt
+   mkdir -p ${WRKBUILD}/qt
# qt config options taken from scripts/build.py
cd ${WRKBUILD}/qt && \
env -i ${CONFIGURE_ENV} ${WRKSRC}/qt/configure \
Index: patches/patch-qt_mkspecs_openbsd-g++_qmake_conf
===
RCS file: patches/patch-qt_mkspecs_openbsd-g++_qmake_conf
diff -N patches/patch-qt_mkspecs_openbsd-g++_qmake_conf
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-qt_mkspecs_openbsd-g++_qmake_conf 1 Mar 2017 12:12:09 
-
@@ -0,0 +1,36 @@
+$OpenBSD$
+--- qt/mkspecs/openbsd-g++/qmake.conf.orig Wed Mar  1 12:02:31 2017
 qt/mkspecs/openbsd-g++/qmake.conf  Wed Mar  1 12:03:23 2017
+@@ -8,7 +8,7 @@ TEMPLATE   = app
+ CONFIG+= qt warn_on release link_prl gdb_dwarf_index
+ QT+= core gui
+ 
+-QMAKE_CC  = gcc
++QMAKE_CC  = ${CC}
+ QMAKE_LEX = flex
+ QMAKE_LEXFLAGS=
+ QMAKE_YACC= yacc
+@@ -24,7 +24,7 @@ QMAKE_CFLAGS_STATIC_LIB  = $$QMAKE_CFLAGS_SHLIB
+ QMAKE_CFLAGS_YACC = -Wno-unused -Wno-parentheses
+ QMAKE_CFLAGS_THREAD   = -pthread
+ 
+-QMAKE_CXX = g++
++QMAKE_CXX = ${CXX}
+ QMAKE_CXXFLAGS= $$QMAKE_CFLAGS
+ QMAKE_CXXFLAGS_DEPS   = $$QMAKE_CFLAGS_DEPS
+ QMAKE_CXXFLAGS_WARN_ON= $$QMAKE_CFLAGS_WARN_ON
+@@ -45,10 +45,10 @@ QMAKE_LIBDIR_QT= $$[QT_INSTALL_LIBS]
+ QMAKE_INCDIR_OPENGL   = /usr/X11R6/include
+ QMAKE_LIBDIR_OPENGL   = /usr/X11R6/lib
+ 
+-QMAKE_LINK= g++
+-QMAKE_LINK_SHLIB  = g++
+-QMAKE_LINK_C  = gcc
+-QMAKE_LINK_C_SHLIB= gcc
++QMAKE_LINK= $$QMAKE_CXX
++QMAKE_LINK_SHLIB  = $$QMAKE_CXX
++QMAKE_LINK_C  = $$QMAKE_CC
++QMAKE_LINK_C_SHLIB= $$QMAKE_CC
+ QMAKE_LINK_SHLIB_CMD  = $$QMAKE_LINK_SHLIB $(LFLAGS) \
+   $$QMAKE_CFLAGS_SHLIB $$QMAKE_LFLAGS \
+   -o $(TARGETD) $(OBJECTS) $(OBJMOC) $(LIBS)



Re: Ports with hardcoded "gcc", "g++"

2017-03-01 Thread Frank Groeneveld
On Tue, Feb 28, 2017, at 14:03, Christian Weisgerber wrote:
> textproc/wkhtmltopdf Frank Groeneveld 

I've been trying to fix textporc/wkhtmltopdf in the last few days, but
can't seem to make qmake use the correct compiler. The do-configure step
of this port configures the patched QT that is part of the port. I've
tried adding CXX="${CXX}" and/or SYS_CXX="${CXX}" to the env of that
step, but it seems to be unused. Anybody got some hints on how to fix
this one?

Thanks!
Frank



Re: Ports with hardcoded "gcc", "g++"

2017-02-28 Thread Gleydson Soares
> The fixes that have been committed have unlocked additional parts
> of the ports tree, revealing new build failures.  Here is an updated
> list.  I've added the MAINTAINERs
..
> plan9/devdrawserver Gleydson Soares 

fixed.



Re: Ports with hardcoded "gcc", "g++"

2017-02-28 Thread Juan Francisco Cantero Hurtado
On Tue, Feb 28, 2017 at 01:03:38PM +, Christian Weisgerber wrote:
> The fixes that have been committed have unlocked additional parts
> of the ports tree, revealing new build failures.  Here is an updated
> list.  I've added the MAINTAINERs.
> 
> lang/nimThe OpenBSD ports mailing-list 

I've a patch for nim from two or three days ago. It builds the package
but I don't find where is the gcc command in the tests and I don't want
commit the changes without to run first the tests.

-- 
Juan Francisco Cantero Hurtado http://juanfra.info



Re: Ports with hardcoded "gcc", "g++"

2017-02-28 Thread Christian Weisgerber
The fixes that have been committed have unlocked additional parts
of the ports tree, revealing new build failures.  Here is an updated
list.  I've added the MAINTAINERs.

archivers/hs-zlib   Matthias Kilian 
audio/gogglesmm The OpenBSD ports mailing-list 
databases/hs-postgresql-libpq David Schaefer 
databases/riak  Jonathan Matthew 
devel/boost Brad Smith 
devel/cil   The OpenBSD ports mailing-list 
devel/hs-bytestring-mmap Matthias Kilian 
devel/hs-hinotify   The OpenBSD ports mailing-list 
devel/hs-lifted-base Matthias Kilian 
devel/hs-networkMatthias Kilian 
devel/hs-old-time   Matthias Kilian 
devel/hs-primitive  Jim Razmus II 
devel/hs-readline   Matthias Kilian 
devel/hs-regex-posix Matthias Kilian 
devel/hs-unix-compat Jim Razmus II 
devel/jdk/1.7   Kurt Miller 
devel/libfmtMarkus Friedl 
devel/ocaml-curses  The OpenBSD ports mailing-list 
devel/py-sipThe OpenBSD ports mailing-list 
devel/radare2/main  Edd Barrett 
games/ioquake3  Aaron Bieber 
games/roadfighter   The OpenBSD ports mailing-list 
games/teeworlds Donovan Watteau 
games/tome4 Solene Rapenne 
games/wordwarvi Pascal Stumpf 
geo/osm2go  The OpenBSD ports mailing-list 
graphics/birdfont   Jasper Lievisse Adriaanse 
graphics/hs-OpenGLRaw Matthias Kilian 
lang/nimThe OpenBSD ports mailing-list 
lang/squeak/vm  Marc Espie 
misc/rocrailSebastian Reitenbach 
misc/wmtimerThe OpenBSD ports mailing-list 
net/clogThe OpenBSD ports mailing-list 
net/dysnomiaThe OpenBSD ports mailing-list 
net/hs-curl David Schaefer 
net/hs-network-info David Schaefer 
net/olsrd   Martin Reindl 
net/pidgin  Brad Smith 
net/spectrum-tools  The OpenBSD ports mailing-list 
plan9/devdrawserver Gleydson Soares 
productivity/wyrd   Okan Demirmen 
security/hs-skein   The OpenBSD ports mailing-list 
security/ssh-askpass-fullscreen The OpenBSD ports mailing-list 

textproc/hs-libxml-sax David Coppa 
textproc/pilot_makedoc The OpenBSD ports mailing-list 
textproc/wkhtmltopdf Frank Groeneveld 
www/iridium Robert Nagy 
www/phantomjs   Francisco de Borja Lopez Rio 
x11/hs-X11  Matthias Kilian 
x11/isomaster   Giovanni Bechis 
x11/p5-Wx   The OpenBSD ports mailing-list 
x11/qt3 Marc Espie 
x11/qt4 Marc Espie 
x11/roxterm The OpenBSD ports mailing-list 

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



Re: Ports with hardcoded "gcc", "g++"

2017-02-27 Thread Gleydson Soares

> plan9/plan9port
fixed.



Re: Ports with hardcoded "gcc", "g++"

2017-02-27 Thread Matthias Kilian
Hi,

On Mon, Feb 27, 2017 at 09:06:22PM +0100, Jeremie Courreges-Anglas wrote:
> TODO
> 
[...]
> >> lang/ghc

This one is weird. It has "autodetection", but just setting CC="${CC}"
doesn't work, so I've added --with-ghc="${CC}", which seems to work
(with /usr/bin/gcc and /usr/bin/g++ removed). For the switch to
clang, I also added --with-clang="${CC}", but I've no idea wether
this will work or not.

Anyway, when my ghc build finishes sucessfully, I'll put the diff
below in.

Ciao,
Kili

Index: Makefile
===
RCS file: /cvs/ports/lang/ghc/Makefile,v
retrieving revision 1.143
diff -u -p -r1.143 Makefile
--- Makefile1 Nov 2016 18:14:05 -   1.143
+++ Makefile27 Feb 2017 22:42:12 -
@@ -106,7 +106,9 @@ CFLAGS +=   -fno-pie
 
 CONFIGURE_STYLE =  gnu
 CONFIGURE_ARGS +=  --with-iconv-includes=${LOCALBASE}/include \
-   --with-iconv-libraries=${LOCALBASE}/lib
+   --with-iconv-libraries=${LOCALBASE}/lib \
+   --with-gcc="${CC}" \
+   --with-clang="${CC}"
 # XXX: wxneeded is a hack. Fix rts/Linker.c, mmapForLinker() and
 #  loadObj_() instead.
 CONFIGURE_ENV +=   CONF_CC_OPTS_STAGE0="-fno-pie -nopie" \
@@ -161,7 +163,9 @@ post-patch:
 # - Install a precompiled binary.
cd ${WRKDIR}/ghc-${BIN_VER} && \
LD_LIBRARY_PATH=${BOOTSTRAP_SHLIBS} \
-   ./configure --prefix=${WRKDIR}/bootstrap && \
+   ./configure --prefix=${WRKDIR}/bootstrap \
+   --with-gcc="${CC}" \
+   --with-clang="${CC}" && \
LD_LIBRARY_PATH=${BOOTSTRAP_SHLIBS} \
${MAKE_PROGRAM} install
rm -rf ${WRKDIR}/ghc-${BIN_VER}



Re: Ports with hardcoded "gcc", "g++"

2017-02-27 Thread Jeremie Courreges-Anglas
Stuart Henderson  writes:

> On 2017/02/26 16:00, Christian Weisgerber wrote:
>> Ports are supposed to honor the CC and CXX variables.  (There are
>> some exceptions such as perl and imake ports that pick up a central
>> setting.)  They are not supposed to have hardcoded compiler names.
>> In particular they should not call "gcc" or "g++".  Alas, this has
>> never been strictly enfored, so numerous offenders have slipped in.
>> 
>> At least clang architectures will no longer have a /usr/bin/gcc or
>> /usr/bin/g++.
>> 
>> Fortunately, this is easy to test anywhere: just rm /usr/bin/gcc
>> and /usr/bin/g++.  You can hardlink them back afterwards.
>> 
>> Here is a first batch of ports that fail to build without "gcc" or
>> "g++" being present.  More will come to light eventually.  At the
>> moment, failing dependencies prevent about a third of the ports
>> tree from being built.
>
> I've fixed a handful (mostly just adding CC="${CC}" and/or
> CXX="${CXX}" to MAKE_FLAGS, though some needed more work)
>
>> audio/mp3gain
>> comms/zmtx-zmrx
>> converters/html2text
>> misc/figlet
>> net/ssvnc
>> net/vncsnapshot
>> telephony/astmanproxy
>> security/p0f3
>
> ...
>
> These ones are most likely qmake-related
>
>> devel/py-sip
>> textproc/wkhtmltopdf
>> www/phantomjs
>
> ..
>

Ports that should be fine now (fixed by various)

>> audio/goattracker
>> biology/nutdb
>> chinese/crxvt
>> comms/colrdx
>> comms/owx
>> converters/lastools
>> converters/mimepp

>> devel/jsoncpp
>> devel/libutf
>> devel/premake4
>> devel/pysvn
>> devel/radare2/main
>> editors/tweak

>> graphics/s10sh

>> mail/archiveopteryx
>> mail/bmf

>> math/aamath
>> math/libneural
>> math/libtommath
>> math/minisat
>> math/xspread

>> misc/randtype
>> misc/xd
>> multimedia/avinfo

>> net/osrtspproxy
>> plan9/drawterm

>> security/foremost
>> security/ipguard
>> sysutils/incron

>> textproc/rman

>> www/cntlm

>> x11/windowlab
>> x11/xmold


TODO


(There's a removal proposal pending for clog and pilot_makedoc.)

>> devel/arm-none-eabi/gcc-linaro
>> devel/avr/gcc
>> devel/boost

>> emulators/sdlmame
>> emulators/sdlmess
>> games/blockrage
>> games/capitan-sevilla
>> games/einstein
>> games/gemdropx
>> games/icebreaker
>> games/netris
>> games/sdlpop
>> games/teeworlds
>> games/typespeed

>> lang/ghc
>> lang/libv8
>> lang/mruby
>> lang/nim
>> lang/ocaml
>> lang/squeak/vm

>> math/suitesparse

XXX kill?
>> net/clog

>> net/ftpcopy

>> plan9/plan9port

>> textproc/heirloom-doctools
>> textproc/libxmlbird

XXX kill?
>> textproc/pilot_makedoc

>> www/netsurf/netsurf-fb
>> www/swiggle
>> x11/goggles

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: Ports with hardcoded "gcc", "g++"

2017-02-26 Thread Stuart Henderson
On 2017/02/26 16:00, Christian Weisgerber wrote:
> Ports are supposed to honor the CC and CXX variables.  (There are
> some exceptions such as perl and imake ports that pick up a central
> setting.)  They are not supposed to have hardcoded compiler names.
> In particular they should not call "gcc" or "g++".  Alas, this has
> never been strictly enfored, so numerous offenders have slipped in.
> 
> At least clang architectures will no longer have a /usr/bin/gcc or
> /usr/bin/g++.
> 
> Fortunately, this is easy to test anywhere: just rm /usr/bin/gcc
> and /usr/bin/g++.  You can hardlink them back afterwards.
> 
> Here is a first batch of ports that fail to build without "gcc" or
> "g++" being present.  More will come to light eventually.  At the
> moment, failing dependencies prevent about a third of the ports
> tree from being built.

I've fixed a handful (mostly just adding CC="${CC}" and/or
CXX="${CXX}" to MAKE_FLAGS, though some needed more work)

> audio/mp3gain
> comms/zmtx-zmrx
> converters/html2text
> misc/figlet
> net/ssvnc
> net/vncsnapshot
> telephony/astmanproxy
> security/p0f3

...

These ones are most likely qmake-related

> devel/py-sip
> textproc/wkhtmltopdf
> www/phantomjs

..

> audio/goattracker
> biology/nutdb
> chinese/crxvt
> comms/colrdx
> comms/owx
> converters/lastools
> converters/mimepp
> devel/arm-none-eabi/gcc-linaro
> devel/avr/gcc
> devel/boost
> devel/jsoncpp
> devel/libutf
> devel/premake4
> devel/pysvn
> devel/radare2/main
> editors/tweak
> emulators/sdlmame
> emulators/sdlmess
> games/blockrage
> games/capitan-sevilla
> games/einstein
> games/gemdropx
> games/icebreaker
> games/netris
> games/sdlpop
> games/teeworlds
> games/typespeed
> graphics/s10sh
> lang/ghc
> lang/libv8
> lang/mruby
> lang/nim
> lang/ocaml
> lang/squeak/vm
> mail/archiveopteryx
> mail/bmf
> math/aamath
> math/libneural
> math/libtommath
> math/minisat
> math/suitesparse
> math/xspread
> misc/randtype
> misc/xd
> multimedia/avinfo
> net/clog
> net/ftpcopy
> net/osrtspproxy
> plan9/drawterm
> plan9/plan9port
> security/foremost
> security/ipguard
> sysutils/incron
> textproc/heirloom-doctools
> textproc/libxmlbird
> textproc/pilot_makedoc
> textproc/rman
> www/cntlm
> www/netsurf/netsurf-fb
> www/swiggle
> x11/goggles
> x11/windowlab
> x11/xmold
> 
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de
> 



Re: Ports with hardcoded "gcc", "g++"

2017-02-26 Thread Antoine Jacoutot
On Sun, Feb 26, 2017 at 04:00:16PM +0100, Christian Weisgerber wrote:
> Ports are supposed to honor the CC and CXX variables.  (There are
> some exceptions such as perl and imake ports that pick up a central
> setting.)  They are not supposed to have hardcoded compiler names.
> In particular they should not call "gcc" or "g++".  Alas, this has
> never been strictly enfored, so numerous offenders have slipped in.
> 
> At least clang architectures will no longer have a /usr/bin/gcc or
> /usr/bin/g++.
> 
> Fortunately, this is easy to test anywhere: just rm /usr/bin/gcc
> and /usr/bin/g++.  You can hardlink them back afterwards.
> 
> Here is a first batch of ports that fail to build without "gcc" or
> "g++" being present.  More will come to light eventually.  At the
> moment, failing dependencies prevent about a third of the ports
> tree from being built.

There's also Qt that hardcodes gcc and g++ IIRC (QMAKE_CC or something like
that in the default qmake.conf).

 
> audio/goattracker
> audio/mp3gain
> biology/nutdb
> chinese/crxvt
> comms/colrdx
> comms/owx
> comms/zmtx-zmrx
> converters/html2text
> converters/lastools
> converters/mimepp
> devel/arm-none-eabi/gcc-linaro
> devel/avr/gcc
> devel/boost
> devel/jsoncpp
> devel/libutf
> devel/premake4
> devel/py-sip
> devel/pysvn
> devel/radare2/main
> editors/tweak
> emulators/sdlmame
> emulators/sdlmess
> games/blockrage
> games/capitan-sevilla
> games/einstein
> games/gemdropx
> games/icebreaker
> games/netris
> games/sdlpop
> games/teeworlds
> games/typespeed
> graphics/s10sh
> lang/ghc
> lang/libv8
> lang/mruby
> lang/nim
> lang/ocaml
> lang/squeak/vm
> mail/archiveopteryx
> mail/bmf
> math/aamath
> math/libneural
> math/libtommath
> math/minisat
> math/suitesparse
> math/xspread
> misc/figlet
> misc/randtype
> misc/xd
> multimedia/avinfo
> net/clog
> net/ftpcopy
> net/osrtspproxy
> net/ssvnc
> net/vncsnapshot
> plan9/drawterm
> plan9/plan9port
> security/foremost
> security/ipguard
> security/p0f3
> sysutils/incron
> telephony/astmanproxy
> textproc/heirloom-doctools
> textproc/libxmlbird
> textproc/pilot_makedoc
> textproc/rman
> textproc/wkhtmltopdf
> www/cntlm
> www/netsurf/netsurf-fb
> www/phantomjs
> www/swiggle
> x11/goggles
> x11/windowlab
> x11/xmold
> 
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de
> 

-- 
Antoine



Ports with hardcoded "gcc", "g++"

2017-02-26 Thread Christian Weisgerber
Ports are supposed to honor the CC and CXX variables.  (There are
some exceptions such as perl and imake ports that pick up a central
setting.)  They are not supposed to have hardcoded compiler names.
In particular they should not call "gcc" or "g++".  Alas, this has
never been strictly enfored, so numerous offenders have slipped in.

At least clang architectures will no longer have a /usr/bin/gcc or
/usr/bin/g++.

Fortunately, this is easy to test anywhere: just rm /usr/bin/gcc
and /usr/bin/g++.  You can hardlink them back afterwards.

Here is a first batch of ports that fail to build without "gcc" or
"g++" being present.  More will come to light eventually.  At the
moment, failing dependencies prevent about a third of the ports
tree from being built.

audio/goattracker
audio/mp3gain
biology/nutdb
chinese/crxvt
comms/colrdx
comms/owx
comms/zmtx-zmrx
converters/html2text
converters/lastools
converters/mimepp
devel/arm-none-eabi/gcc-linaro
devel/avr/gcc
devel/boost
devel/jsoncpp
devel/libutf
devel/premake4
devel/py-sip
devel/pysvn
devel/radare2/main
editors/tweak
emulators/sdlmame
emulators/sdlmess
games/blockrage
games/capitan-sevilla
games/einstein
games/gemdropx
games/icebreaker
games/netris
games/sdlpop
games/teeworlds
games/typespeed
graphics/s10sh
lang/ghc
lang/libv8
lang/mruby
lang/nim
lang/ocaml
lang/squeak/vm
mail/archiveopteryx
mail/bmf
math/aamath
math/libneural
math/libtommath
math/minisat
math/suitesparse
math/xspread
misc/figlet
misc/randtype
misc/xd
multimedia/avinfo
net/clog
net/ftpcopy
net/osrtspproxy
net/ssvnc
net/vncsnapshot
plan9/drawterm
plan9/plan9port
security/foremost
security/ipguard
security/p0f3
sysutils/incron
telephony/astmanproxy
textproc/heirloom-doctools
textproc/libxmlbird
textproc/pilot_makedoc
textproc/rman
textproc/wkhtmltopdf
www/cntlm
www/netsurf/netsurf-fb
www/phantomjs
www/swiggle
x11/goggles
x11/windowlab
x11/xmold

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de