Hi Shashwat,
- On 9 Mar, 2015, at 00:36, Shashwat Pandey devshashwatpan...@gmail.com
wrote:
> 'Speed up trace mode' suggests implementation of a cache data structure to
> improve performance of trace mode.
>
> I have been trying to understand the code related to trace mode. The
> darwintrac
Hi Ryan and Rainer,
turns out that this happened AGAIN [1]:
On 04 Nov 2014, at 07:10 , Ryan Schmidt wrote:
> Great, so it sounds like the original problem that led to the files being
> directly installed has already been fixed, and all that we need to do now is
> delete those files before acti
Yes, that's true: I can have any number, and they are executed in the
order declared. The Octave PortGroup's post-patch would always be
declared first, and it (1) creates a tarball of the current worksrcpath,
then (2) deletes the worksrcpath since it is not used by the Octave pkg
installer. So, if
> On Mar 9, 2015, at 11:49 AM, michae...@macports.org wrote:
>
> Revision
> 133725
> Author
> michae...@macports.org
> Date
> 2015-03-09 09:49:23 -0700 (Mon, 09 Mar 2015)
> Log Message
>
> octave 1.0 PortGroup: combine post-patch and pre-configure into the latter
> only, to allow for using post
On 2015-03-09 12:30, Clemens Lang wrote:
>
>> Are there stats what percentage of the current ports build without Xcode
>> installed? I have a hunch you'll find that a good part do depend on the SDK
>> if
>> not only because Qt (and presumable GTk{2,3}) use CoreFoundation and Carbon
>> ...
>
> N
On Mar 9, 2015, at 8:42 AM, René J.V. Bertin wrote:
>
> Where is there architecture order defined for ports that do 2 (or more)
> completely separate builds that are merged afterwards (= use the muniversal
> PortGroup, I think)?
> It currently starts with 64bit build, but I'd like it to start wi
Hi,
Where is there architecture order defined for ports that do 2 (or more)
completely separate builds that are merged afterwards (= use the muniversal
PortGroup, I think)?
It currently starts with 64bit build, but I'd like it to start with the 32bit
build (so I don't have to wait for the known
Hi,
- On 9 Mar, 2015, at 13:12, René J.V. Bertin rjvber...@gmail.com wrote:
> Interesting, given the trouble I encountered when I installed the latest CLT
> instead of the latest Xcode (because of reported issues with the IDE). Maybe
> those were because I did have an older Xcode version in p
On Monday March 09 2015 12:30:40 Clemens Lang wrote:
> No, there are no stats, simply because we don't know. Personal experience says
> almost all of my ports built without Xcode when upgrading to Yosemite, where I
> did not install Xcode on purpose to test exactly that.
Interesting, given the tr
On Mar 9, 2015, at 06:02, Jackson Isaac wrote:
>
> But when I try 'port -d sync', it says I need to run 'port
> selfupdate'. My University network blocks rsync.
selfupdate always uses rsync; it cannot be configured to use another method. If
your network blocks rsync, then you cannot use the self
> Are there stats what percentage of the current ports build without Xcode
> installed? I have a hunch you'll find that a good part do depend on the SDK if
> not only because Qt (and presumable GTk{2,3}) use CoreFoundation and Carbon
> ...
No, there are no stats, simply because we don't know. Pe
Hi,
I have followed the steps as mentioned at
http://trac.macports.org/wiki/howto/SyncingWithSVN
But when I try 'port -d sync', it says I need to run 'port
selfupdate'. My University network blocks rsync.
Jacksons-MacBook-Pro:~ JacksonIsaac$ sudo port -d sync
Password:
DEBUG: Copying /Users/Jack
On Monday March 09 2015 10:38:20 Clemens Lang wrote:
>Additionally, it wouldn't solve the problem. When passing the complete path to
>any syscalls, the same problem would occur.
Doh. Of course...
___
macports-dev mailing list
macports-dev@lists.macosf
On Monday March 09 2015 10:54:55 Mojca Miklavec wrote:
>> What happens when you set workpath to something short like /tmp/mp ?
>
>After you wait for hours and hours for your "port build qt5-something"
>to finish (or rather break with some compile error), you figure out
>that you need to go home. Y
On Monday March 09 2015 10:35:26 Clemens Lang wrote:
Hi,
>I don't know. It's part of the task to find out. Somehow the Command Line Tools
>succeed in producing working code without an Xcode installation and don't ship
>an SDK, so I'm assuming they are not needed for most ports.
Are there stats wh
On Mon, Mar 9, 2015 at 10:48 AM, René J.V. wrote:
> On Monday March 09 2015 10:28:36 Mojca Miklavec wrote:
>
>>I certainly agree that at some point it might make sense to allow
>>building ports in some path with a very short prefix.
>
> What happens when you set workpath to something short like /tm
On Monday March 09 2015 10:28:36 Mojca Miklavec wrote:
>It's probably a tiny bit of everyone's fault. MacPorts also generates
>potentially insanely long folder names. It starts with things like
>
> _opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_subversion-perlb
- On 9 Mar, 2015, at 10:08, René J.V. Bertin rjvber...@gmail.com wrote:
> In fact, couldn't the trick used by tracemode be used also to map between a
> virtual, compact and readable path visible to the build process and the real
> ${workpath}? That would really be nice just for readability .
Hi,
- On 9 Mar, 2015, at 10:13, René J.V. Bertin rjvber...@gmail.com wrote:
> All of Xcode? Doesn't that block access to the SDKs too, and is that going to
> require the use of a compiler installed through MacPorts?
I don't know. It's part of the task to find out. Somehow the Command Line To
On Mon, Mar 9, 2015 at 10:08 AM, René J.V. wrote:
> On Sunday March 08 2015 23:25:53 Ryan Schmidt wrote:
>
>>
>>I agree, those filenames are too long. Whatever is creating those long
>>filenames should rethink that strategy. I don't know what's creating those
>>filenames, only that it's not MacPo
On Monday March 09 2015 12:09:20 Jackson Isaac wrote:
>> > *2. Phase out dependency on Xcode completely *- Here are we going to use
...
>> No, the idea here is to use trace mode (an LD_PRELOAD-based sandbox that
>> hides files a port does not explicitly depend on) to hide the Xcode
All of Xcode? D
On Sunday March 08 2015 23:25:53 Ryan Schmidt wrote:
>
>I agree, those filenames are too long. Whatever is creating those long
>filenames should rethink that strategy. I don't know what's creating those
>filenames, only that it's not MacPorts.
I CC'ed here mostly to see if any port maintainers
22 matches
Mail list logo
