On Dec 11, 2014, at 4:07 AM, René J.V. Bertin rjvber...@gmail.com wrote:
It'd also be very helpful if there were an override simply for the portfile
has changed, cleaning everything feature.
The -o option does this. Check the port(1) manpage.
vq
Sent from my iPhone
On Thursday December 11 2014 05:33:30 Lawrence Velázquez wrote:
The -o option does this. Check the port(1) manpage.
Ah, has this behaviour been modified lately? I remember it didn't always work
as I expected.
BTW, does this update the sha tag in the statefile, or will I still get a `port
On Dec 11, 2014, at 5:31 AM, René J.V. Bertin wrote:
On Thursday December 11 2014 05:33:30 Lawrence Velázquez wrote:
The -o option does this. Check the port(1) manpage.
Ah, has this behaviour been modified lately? I remember it didn't always work
as I expected.
I'm not aware of any
On Dec 10, 2014, at 1:27 PM, René J.V. Bertin wrote:
On Wednesday December 10 2014 12:20:58 Ryan Schmidt wrote:
The thing is, if ever we want to allow Qt4 and Qt5 to be present at the
same time, the installation location will *have* to change, and dependent
ports will have to comply with
On Thu, Dec 11, 2014 at 4:07 AM, René J.V. rjvber...@gmail.com wrote:
How about a main port with the new paths, and a stub port or subport that
depends on the main port, conflicts with qt4-mac, and installs the
symlinks? Then we can replace qt4-mac with the stub port at some point.
I like
Hi,
Taking a break from qt4-mac next generation I'm giving some love to my port
for qtchooser.
Problem: whatever magic ensures that things get installed into ${destroot}
first doesn't work with this project and its hand-written Makefile.
As a result, `port destroot qtchooser` installs things
Hi René - If the Makefile is hand-written, it probably does not contain
a way to set DESTROOT or some other variable to direct where to install
stuff outside of PREFIX -- you'll need to read through the Makefile to
verify, generally in the install: section. If this is this case, you
have to add
On Thursday December 11 2014 11:53:00 Michael Dickens wrote:
Hi
Hi René - If the Makefile is hand-written, it probably does not contain
a way to set DESTROOT or some other variable to direct where to install
stuff outside of PREFIX -- you'll need to read through the Makefile to
No, it
On Dec 11, 2014, at 9:21 AM, René J.V. Bertin rjvber...@gmail.com wrote:
Yes, I have willingly not provided a mechanism to avoid breakage of ports
installed against +concurrent.
But remember that I did try to set +concurrent by default if qt4-mac is
installed that way.
We have to consider
On Dec 11, 2014, at 12:38 PM, René J.V. Bertin rjvber...@gmail.com wrote:
On Thursday December 11 2014 11:53:00 Michael Dickens wrote:
Hi René - If the Makefile is hand-written, it probably does not contain
a way to set DESTROOT or some other variable to direct where to install
stuff
On Thu, Dec 11, 2014, at 12:38 PM, René J.V. Bertin wrote:
On Thursday December 11 2014 11:53:00 Michael Dickens wrote:
Hi René - If the Makefile is hand-written, it probably does not contain
a way to set DESTROOT or some other variable to direct where to install
stuff outside of PREFIX --
On Thursday December 11 2014 12:41:03 Lawrence Velázquez wrote:
Don't rely on rev-upgrade in lieu of proper revbumping. Don't assume that
everyone uses binaries.
Only the binaries change location, plus the cmake files. And those are found
dynamically.
Wouldn't the dependents have to be
On Thursday December 11 2014 12:52:55 Lawrence Velázquez wrote:
We already pass DESTDIR=$destroot to the make invocation. Make can't force a
makefile to use it.
See, that's the bit I was missing :)
cd qtchooser*
git init
git add .[a-zA-Z0-9]* *
git commit -a -m init
}}}
Then, open the
On Thu, Dec 11, 2014 at 1:42 PM, René J.V. rjvber...@gmail.com wrote:
We already pass DESTDIR=$destroot to the make invocation. Make can't
force a makefile to use it.
See, that's the bit I was missing :)
It's only the same thing RPM has conditioned Linux devs into doing for
years now
On Dec 11, 2014, at 10:53 AM, Michael Dickens wrote:
If the Makefile is hand-written, it probably does not contain a way to set
DESTROOT or some other variable to direct where to install stuff outside of
PREFIX
That's not necessarily so. Humans are certainly capable of writing Makefiles
On Dec 10, 2014, at 8:12 PM, Lawrence Velázquez lar...@macports.org wrote:
On Dec 10, 2014, at 3:39 PM, Lawrence Velázquez lar...@macports.org wrote:
On Dec 10, 2014, at 2:03 PM, Ray Zimmerman r...@cornell.edu wrote:
:info:build dyld: Library not loaded: /opt/local/lib/libedit.0.dylib
On Thursday December 11 2014 13:56:52 Ryan Schmidt wrote:
On Dec 11, 2014, at 10:53 AM, Michael Dickens wrote:
If the Makefile is hand-written, it probably does not contain a way to set
DESTROOT or some other variable to direct where to install stuff outside of
PREFIX
That's not
On Dec 11, 2014, at 3:14 PM, René J.V. Bertin rjvber...@gmail.com wrote:
question does not do so, consider fixing the Makefile to do so, then
providing a patch to the developers so that they can include it in the next
version
The Makefiles in question already contained INSTALL_ROOT. I
On Dec 11, 2014, at 3:14 PM, René J.V. Bertin rjvber...@gmail.com wrote:
The Makefiles in question already contained INSTALL_ROOT. I doubt that the
developer would be interested in replacing that with DESTDIR...
so you just need to set destroot.destdir INSTALL_ROOT=${destroot}
--
Daniel J.
On Thursday December 11 2014 15:32:03 Lawrence Velázquez wrote:
Using DESTDIR is a pretty common convention for Unix-y build systems. Is
INSTALL_ROOT the convention somewhere else?
I think it's what qmake produces, so it would be a Qt convention - which would
be pretty appropriate.
On Thu, Dec 11, 2014, at 03:13 PM, Ray Zimmerman wrote:
Now back to my original goal, getting multiple versions of octave installed …
if I now do the following to build version 3.6.4 of Octave …
svn co -r 121949
http://svn.macports.org/repository/macports/trunk/dports/math/octave
cd
Not to be the OT police, but all the recent portfile development
discussion on this list would be much more at home on macports-dev.
- Josh
___
macports-users mailing list
macports-users@lists.macosforge.org
Following a recent update to Yosemite, I have reinstalled Xcode and
Macports. Upon running install Gimp2 followed by install ufraw, there is
no evidence e of Wilber in the Macport folder in Applications. I have read
that Wilber should be in the Macports folder and he isn't I have searched
all the
On Thu, Dec 11, 2014 at 4:30 PM, David Lyon sa...@verizon.net wrote:
Following a recent update to Yosemite, I have reinstalled Xcode and
Macports. Upon running install Gimp2 followed by install ufraw, there is
no evidence e of Wilber in the Macport folder in Applications. I have read
that
24 matches
Mail list logo
