I forgot about the limitation. Thanks for letting me know.
On 2013/10/25, at 21:47, Ryan Schmidt wrote:
>
> On Oct 25, 2013, at 01:43, takan...@macports.org wrote:
>
>> +variant hiragino conflicts yu description {Use Hiragino fonts for
>> typesetting} {}
>> +variant yu conflicts hiragino descr
> Are they not as interchangeable as I thought?
Right. The data structure differs between the two container libraries.
I.e. ChaSen which is linked against Darts-clone cannot read the dictionary
files
produced by ChaSen linked against the original Darts, and vice versa.
So we had to add +dartsclo
> (Incidentally, pTeX itself is also available in texlive, with the
> texlive-lang-cjk port, but I haven't tried it myself.)
pTeX in TeX Live 2010 works well in many cases.
I believe most of pTeX users can shift to TeX Live 2010.
Strictly speaking, pTeX in TeX Live 2010 is not upper compatible
w
If you have any better ways let me know.
On 2010/12/03, at 14:38, Jeremy Lavergne wrote:
>> Increased revision number to link against the new library. (icu 4.6)
>> ...
>> • trunk/dports/devel/boost/Portfile
>
> And everyone cried.
>
> ___
> macpo
> Variant names should not begin with "with_" (or "without_" or "enable_" or
> "disable_").
> They should either begin with nothing (preferred), or "no_".
As you say, +with_doxygen may be a bit redundant.
> Why is build_arch relevant for the universal variant? Shouldn't only
> universal_archs
Hi,
I bumped up revision numbers of the following ports. (r71219)
Thanks for letting me know about it, André!
devel/caml-pcre/Portfile
devel/camlimages/Portfile
gnome/ggv/Portfile
gnome/gpdf/Portfile
graphics/ImageMagick/Portfile
graphics/asymptote/Portfile
graphics/graphviz-devel/Portfile
graphi
I see, thanks a lot!
On 2010/04/01, at 20:36, Ryan Schmidt wrote:
>
> On Apr 1, 2010, at 06:35, takan...@macports.org wrote:
>
>> Revision: 65818
>> http://trac.macports.org/changeset/65818
>> Author: takan...@macports.org
>> Date: 2010-04-01 04:35:22 -0700 (Thu, 01 Apr 2010)
>> L
problem/no side effects (if I am not
wrong)
so please don't worry about it so much.
On 2010/03/18, at 8:42, Jeremy Huddleston wrote:
> Yeah... you probably want to use -D_DARWIN_USE_64_BIT_INODE
>
> On Mar 17, 2010, at 00:38, Takanori Yamamoto wrote:
>
>> Anthony,
>
Anthony,
> now it does not use the 64 bits API on 32 bits system.
Thanks for your concern, but there is no regression because
this macro doesn't have any effect on Darwin's libc, I think.
( please try 'grep -R _LARGEFILE64_SOURCE /usr/include/*' )
# And, in my opinion, PostScript file over 4GB i
Interesting.
>Why was this removed, and why was it there in the first place?
I don't know why these lines are there, but it sure is funny.
In my view, these lines make no sense. All or almost all ports should
be able to be compiled with the default compiler, and the default compiler
should not be
Ryan,
I agree with you. The workaround I submitted yesterday seems a bit ugly.
So, I'll rewrite it later using configure.cppflags and configure.ldflags
introduced in v1.4.1. Thanks for pointing out my mistake.
From: Ryan Schmidt <[EMAIL PROTECTED]>
Subject: Re: [25413] trunk/dports/print/ghosts
11 matches
Mail list logo
