On Thu, Dec 11, 2014 at 4:30 PM, David Lyon 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 Wilber should be
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 f
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
https://lists.macosforge.org/mailman/listinfo/
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
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.
> de
On Dec 11, 2014, at 3:14 PM, René J.V. Bertin 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 doubt that th
> On Dec 11, 2014, at 3:14 PM, René J.V. Bertin 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. Luke
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
> On Dec 10, 2014, at 8:12 PM, Lawrence Velázquez wrote:
>
> On Dec 10, 2014, at 3:39 PM, Lawrence Velázquez wrote:
>
>> On Dec 10, 2014, at 2:03 PM, Ray Zimmerman wrote:
>>
>>> :info:build dyld: Library not loaded: /opt/local/lib/libedit.0.dylib
>>> :info:build Referenced from: /opt/local
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 Thu, Dec 11, 2014 at 1:42 PM, René J.V. 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
--
brand
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,
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 r
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 PREF
On 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 Thu, Dec 11, 2014 at 12:38 PM, René J.V. wrote:
> No, it doesn't. I figured I had to edit it, but how?
>
> Alternatively, couldn't I change the destroot command so that it executes
> make with an appropriate set of options?
>
>
You would still have to at least inspect the Makefile to find out
On Dec 11, 2014, at 9:21 AM, René J.V. Bertin 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 all cases, not
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 d
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
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
On Thu, Dec 11, 2014 at 4:07 AM, René J.V. 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 the idea. I
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 c
it just takes one try to find out.
The result of this simple test should be added to the documentation.
On Dec 11, 2014, at 8:45, Ryan Schmidt wrote:
>> BTW, does this update the sha tag in the statefile,
>
> I doubt it.
___
macports-users mailing l
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 a
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
clea
> On Dec 11, 2014, at 4:07 AM, René J.V. Bertin 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
__
26 matches
Mail list logo
