On Sep 18, 2012, at 23:03, Ryan Stonecipher wrote:
> Incrementing the revision (a one-character change) in the shell-fm portfile
> resulted in automatic, unwanted changes to lines in the description.
> I fixed the description before committing the change which incremented the
> port's revision.
On 2012-9-20 10:32 , Jeremy Lavergne wrote:
>> There are plenty of ways to get around this in macports, but I think a port
>> prefix command would make things simpler and should be easy to implement.
>>
>> Thoughts?
>
> Couldn't you just ".." off of the results from `which`?
>
> if [ -f `which
On Sep 19, 2012, at 16:48, Frank Schima wrote:
> Ideally actually would be to move the +examples and +demos variants into
> sub-ports - qt4-mac-examples and qt4-mac-demos.
I was going to suggest the same but you beat me to it!
As for moving to a framework-always install, that seems like a goo
> There are plenty of ways to get around this in macports, but I think a port
> prefix command would make things simpler and should be easy to implement.
>
> Thoughts?
Couldn't you just ".." off of the results from `which`?
if [ -f `which port`/../../etc/bash_completion]; then
. `which port
I currently have the following in my .bashrc
if [ -f `brew --prefix 2>/dev/null`/etc/bash_completion ]; then
. `brew --prefix`/etc/bash_completion
fi
There are plenty of ways to get around this in macports, but I think a port
prefix command would make things
On Sep 19, 2012, at 10:30 AM, Michael Dickens wrote:
> On Sep 19, 2012, at 12:02 PM, Craig Treleaven
> wrote:
>> Appreciate all the effort you have and continue to put into making Qt as
>> painless as possible!
>
> Thanks! And, that's the goal: as painless as possible. qt4-mac is a BIG
> com
On Tue, Sep 18, 2012 at 5:05 AM, Mojca Miklavec
wrote:
> Hello,
>
> I recently received a feature request to add "+emacs_app" option to
> gnuplot in addition to "+emacs":
> http://trac.macports.org/ticket/36135
[snip]
> From that point of view it seems a bit of an overkill to me to provide
>
On Sep 19, 2012, at 8:44 AM, Michael Dickens wrote:
> After some thinking about the amount of effort I've put into relocating
> Qt's frameworks from ${prefix}/lib to ${prefix}/Library/Frameworks, and
> how much more will need to be done -- e.g., for CMake, and pretty much
> any CMake-using port t
On Sep 19, 2012, at 12:02 PM, Craig Treleaven
wrote:
> Appreciate all the effort you have and continue to put into making Qt as
> painless as possible!
Thanks! And, that's the goal: as painless as possible. qt4-mac is a BIG
compile, so I try hard to avoid requiring a recompile any more often
th
At 11:44 AM -0400 9/19/12, Michael Dickens wrote:
After some thinking about the amount of effort I've put into relocating
Qt's frameworks from ${prefix}/lib to ${prefix}/Library/Frameworks, and
how much more will need to be done -- e.g., for CMake, and pretty much
any CMake-using port that tries
After some thinking about the amount of effort I've put into relocating
Qt's frameworks from ${prefix}/lib to ${prefix}/Library/Frameworks, and
how much more will need to be done -- e.g., for CMake, and pretty much
any CMake-using port that tries to find Qt4, to work reliably when
trying to find "q
Bug report submitted:
Bug ID# 12327864.
Craig
(cc list trimmed)
At 11:33 PM -0700 9/18/12, Jeremy Sequoia wrote:
Please definitely file a bug report at http://bugreport.apple.com
The most likely culprit as to what changed is the compiler. Can you
try using configure.compiler=macports-clang-
12 matches
Mail list logo
