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>