On Jul 5, 2014, at 7:54 PM, Jeremy Lavergne wrote:
> Port variants. It indicates which variants are on based on your variants.conf
...and based on the port's defaults. For example:
$ port variants xorg-libxcb
xorg-libxcb has the variants:
docs: Install extra documentation
python25: Use p
Port variants. It indicates which variants are on based on your variants.conf
On July 5, 2014 8:52:08 PM EDT, Jerry wrote:
>Before installing a port, how does one discover the default variants
>for that port? I gather that one could search the port text file for
>"default_variants" but it seems l
Before installing a port, how does one discover the default variants for that
port? I gather that one could search the port text file for "default_variants"
but it seems like there should be a command for this, perhaps port
default_variants foo.
Jerry
___
On Jul 3, 2014, at 7:04 AM, René J.V. Bertin wrote:
>
> On Jul 03, 2014, at 13:43, Mojca Miklavec wrote:
>
>> On Thu, Jul 3, 2014 at 11:45 AM, "René J.V. Bertin" wrote:
>>> Quick question: I have the universal cmake variant installed, and I fail to
>>> see the interest of that. Is there any wa
Hi,
> I'd be satisfied if the icon that was created also shows up on the app
> bundle, in the Finder. Simply copying it from the build folder into the app
> bundle's Resource directory is not enough, of course.
You need an Info.plist file in the Contents folder of the app bundle. It needs
to be a
On Jul 05, 2014, at 22:05, Marko Käning wrote:
> On 05 Jul 2014, at 21:50 , René J.V. Bertin wrote:
>> Sadly that doesn't teach me anything new ... The last icon (icns) related
>> message is that the .icns file was saved in the build directory.
>
> so, if you know where the build directory is
On 05 Jul 2014, at 21:50 , René J.V. Bertin wrote:
> Sadly that doesn't teach me anything new ... The last icon (icns) related
> message is that the .icns file was saved in the build directory.
so, if you know where the build directory is you’re happy, or not?
___
On 05 Jul 2014, at 21:50 , René J.V. Bertin wrote:
> Sadly that doesn't teach me anything new ... The last icon (icns) related
> message is that the .icns file was saved in the build directory.
so, if you know where the build directory is you’re happy, or not?
___
On Jul 05, 2014, at 16:56, Jeremy Lavergne wrote:
> Using trace mode might help in spotting what it is trying to find (port -t
> ...)
Sadly that doesn't teach me anything new ... The last icon (icns) related
message is that the .icns file was saved in the build directory.
R.
_
Hi,
I've actually hit this "issue" today.
I need rst2pdf, which has an (undeclared, I'll fix this) runtime dependency on
py27-Pillow and py27-reportlab.
py27-reportlab currently depends on py27-pil, while newer subports depend on
Pillow.
I've been in touch with the maintainer, I hope I can quo
Hi René,
> Anyone know where icon generation is handled in cmake-based ports? I whipped
> up a
> replacement for the iconutil command using png2icns.
oh, it's very nice that you've found a replacement for the tool. This might
bring back
a lot of application icons of KDE apps on OSX, which has b
Hi,
if you try to create an application from a port, use the
app portgroup:
http://trac.macports.org/browser/trunk/dports/_resources/port1.0/group/app-1.0.tcl
See for instance the quodlibet port using app.icon:
http://trac.macports.org/browser/trunk/dports/python/quodlibet/Portfile
Cheers,
Eric
Hi,
I cannot answer why, but I can confirm what you have seen. Even on OSX10.9,
where the system clang is
MacBookPro ~ > clang -v
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.3.0
Thread model: posix
So I would guess closer to MacPorts clang 3.4 th
Anyone know where icon generation is handled in cmake-based ports? I whipped up
a replacement for the iconutil command using png2icns. The command is picked up
(if it's in /usr/bin ..) and icns files are generated, but they're not copied
into the target appbundles, let alone installed as app ico
In hope it's not completely out of place to discuss this here, but has anyone
else noticed that clang's supposedly better build performance (as opposed to
gcc) is no longer an accurate selling argument, at least for version 3.4?
Comparing build times of a port I'm working on, KDE's rekonq so mo
15 matches
Mail list logo
