Date: Tue, 24 Aug 2010 15:34:09 +0300 From: Andriy Gapon <avg@icyb.net.ua> To: freebsd-ports@FreeBSD.org Subject: maintainer of devel/tmake - mail bounces Message-ID: <4C73BC41.8020200@icyb.net.ua>
next in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------030706000701020207030506
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
I wonder if maintainer of devel/tmake reads this list and just forgot to update
him email address or if the port has become silently unmaintained.
Or something else?
I'll bounce the undelivered email to this list as well.
-------- Original Message --------
Subject: Returned mail: User unknown
Date: Tue, 24 Aug 2010 15:27:03 +0300 (EEST)
From: Mail Delivery Subsystem <MAILER-DAEMON@citadel.icyb.net.ua>
To: <avg@icyb.net.ua>
The original message was received at Tue, 24 Aug 2010 15:26:51 +0300 (EEST)
from porto-e.starpoint.kiev.ua [212.40.38.100]
----- The following addresses had permanent fatal errors -----
<jesse@cs.uni-magdeburg.de>
----- Transcript of session follows -----
... while talking to mail.cs.uni-magdeburg.de.:
>>> RCPT To:<jesse@cs.uni-magdeburg.de>
<<< 550 5.1.1 <jesse@cs.uni-magdeburg.de>... User unknown
550 <jesse@cs.uni-magdeburg.de>... User unknown
--------------030706000701020207030506
Content-Type: message/rfc822;
name="ForwardedMessage.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="ForwardedMessage.eml"
Return-Path: avg@icyb.net.ua
Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua
[212.40.38.100])
by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA06827
for <jesse@cs.uni-magdeburg.de>; Tue, 24 Aug 2010 15:26:51 +0300 (EEST)
(envelope-from avg@icyb.net.ua)
Received: from localhost.topspin.kiev.ua ([127.0.0.1])
by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD))
id 1OnsaY-000HbB-Oa
for jesse@cs.uni-magdeburg.de; Tue, 24 Aug 2010 15:26:50 +0300
Message-ID: <4C73BA89.6040804@icyb.net.ua>
Date: Tue, 24 Aug 2010 15:26:49 +0300
From: Andriy Gapon <avg@icyb.net.ua>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US;
rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2
MIME-Version: 1.0
To: jesse@cs.uni-magdeburg.de
Subject: Fwd: Re: devel/doxygen and non-default gcc
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Please see message below for a problem with non-default gcc (e.g. gcc44) and
port(s) that use tmake.
Looking in lib/unix/generic.t we see:
...
####### Compiler, tools and options
CC ?= #$ Expand("TMAKE_CC");
CXX ?= #$ Expand("TMAKE_CXX");
CFLAGS += #$ Expand("TMAKE_CFLAGS"); ExpandGlue("DEFINES","-D"," -D","");
CXXFLAGS+= #$ Expand("TMAKE_CXXFLAGS"); ExpandGlue("DEFINES","-D"," -D","");
INCPATH = #$ ExpandPath("INCPATH","-I"," -I","");
#$ Config("staticlib") && DisableOutput();
LINK = #$ Expand("TMAKE_LINK");
...
So, CC and CXX are set in such a way that they can be overridden, but LINK can
not be influenced from outside.
We also see that lib/freebsd-g++/tmake.conf sets TMAKE_LINK to g++, TMAKE_CXX
has the same value.
So it seems that changing lib/unix/generic.t so that LINK is defined as follows
should both preserve default behavior and allow LINK to stay in sync with CXX:
LINK = $(CXX)
P.S. and a cosmetic issue - it seems that the port needlessly installs
freebsd-g++/tmake.conf.orig file that's created during patching.
-------- Original Message --------
Subject: Re: devel/doxygen and non-default gcc
Date: Thu, 05 Aug 2010 07:44:29 -0400
From: Naram Qashat <cyberbotx@cyberbotx.com>
To: Andriy Gapon <avg@icyb.net.ua>
On 08/05/10 04:56, Andriy Gapon wrote:
>
> I am trying to build devel/doxygen with gcc44 and in general it works good except
> for one tiny issue.
> Both src/Makefile.doxygen and src/Makefile.doxytag have this block of definitions
> at the beginning:
> CC ?= gcc
> CXX ?= g++
> CFLAGS += -pipe -Wall -W
> CXXFLAGS+= -pipe -Wall -W
> INCPATH = -I../qtools -I/usr/local/include
> LINK = g++
>
> As you can see, CC and CXX can be overridden and they get set to gcc44 and g++44,
> but LINK value is 'hardcoded'.
> I would like to propose to change LINK definition to:
> LINK = ${CXX}
>
> Thanks!
Here's the thing, those files are generated by tmake. I'm not familiar with
tmake enough to know what needs to be done in order to get it to generate a
proper Makefile that has LINK set to the proper value. If you or someone else
is more familiar with it and would know how to fix this, I'll gladly submit a PR
for it, but without knowing how, I am unable to do so.
Thanks,
Naram Qashat
--------------030706000701020207030506--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C73BC41.8020200>