On Tue, Apr 14, 2015 at 11:12 PM, Clemens Lang wrote:
> Hi *,
>
> I am looking for information on our mirroring infrastructure, especially
> on the job that does the initial mirroring and puts it to the
> distfiles.macports.org machine from where all other mirrors download it.
>
> I think there mig
On Apr 14, 2015, at 2:01 PM, Lawrence Velázquez wrote:
> On Apr 14, 2015, at 4:59 PM, Lawrence Velázquez wrote:
>
>> the "environment" is already something specific to *nix.
>
> That is, the term "environment" already has a specific meaning in *nix.
Yes, I don't like the name for that reason
On Apr 14, 2015, at 1:59 PM, Lawrence Velázquez wrote:
> On Apr 14, 2015, at 4:31 PM, Bradley Giesbrecht wrote:
>
>> I opened a ticket for this simple base patch:
>> https://trac.macports.org/ticket/47442
>>
>> My knowledge of tcl and base is limited, I know my code needs cleanup and
>> test
Hi *,
I am looking for information on our mirroring infrastructure, especially
on the job that does the initial mirroring and puts it to the
distfiles.macports.org machine from where all other mirrors download it.
I think there might be a few problems with our mirror setup, since I've
recently se
On Apr 14, 2015, at 4:59 PM, Lawrence Velázquez wrote:
> the "environment" is already something specific to *nix.
That is, the term "environment" already has a specific meaning in *nix.
vq
___
macports-dev mailing list
macports-dev@lists.macosforge.or
On Apr 14, 2015, at 4:31 PM, Bradley Giesbrecht wrote:
> I opened a ticket for this simple base patch:
> https://trac.macports.org/ticket/47442
>
> My knowledge of tcl and base is limited, I know my code needs cleanup and
> tests. Looking for feedback to decide if I should continue.
>
> The go
I opened a ticket for this simple base patch:
https://trac.macports.org/ticket/47442
My knowledge of tcl and base is limited, I know my code needs cleanup and
tests. Looking for feedback to decide if I should continue.
The goal is a simpler way for users to provide env vars.
Votes up or down if
On Tuesday April 14 2015 18:45:20 Clemens Lang wrote:
Hi,
> No. Do not modify upstream packaging to work around a bug in trace mode.
Not upstream, this is something done in the post-destroot (and I'm the original
author of the Portfile)
R.
___
macpo
Hi,
- On 14 Apr, 2015, at 18:02, René J.V. Bertin rjvber...@gmail.com wrote:
> Erm, you may have noticed that I've been spending a lot of time working on the
> Qt ports, so if those symlinks are created by qt4-mac or qt5-mac they do kind
> of relate to my use cases :)
I was talking about you
On Tuesday April 14 2015 17:51:13 Clemens Lang wrote:
Hi
>would slow down trace mode considerably, but it's a bug. You should not rely
>on this behaviour, because it will go away once caching is implemented so the
Well, as I said I only use this as an admittedly rather dirty hack for quick
testi
Hi,
- On 14 Apr, 2015, at 14:16, René J.V. Bertin rjvber...@gmail.com wrote:
> Actually, how would trace mode handle a files "directory" that is in fact a
> symlink to the files directory in another port directory, like with my
> "qt5-mac-angel" empirical port:
>
> qt5-mac-angel:
> Portfile
On Tuesday April 14 2015 10:32:32 Brandon Allbery wrote:
>I was not talking about actually replacing the system libstdc++; you get
>what you deserve if you do that. I would expect something linking against
:)
>an alternative libstdc++ to have some chance to work, though.
I've used macports-gcc-
On 14.04.2015 04:01 PM, Brandon Allbery wrote:
> The main problem is that Apple's own C++ stuff is based on either a
> pre-C++11 libstdc++ or a C++11 libc++. You could probably build an
> official GPL3-d libstdc++ with C++11 support and it would probably even
> work (that being one of the points of
On Tue, Apr 14, 2015 at 10:23 AM, René J.V. wrote:
> >The main problem is that Apple's own C++ stuff is based on either a
> >pre-C++11 libstdc++ or a C++11 libc++. You could probably build an
> official
> >GPL3-d libstdc++ with C++11 support and it would probably even work (that
>
> If that is eq
On Tuesday April 14 2015 10:01:05 Brandon Allbery wrote:
>Why would they? They don't use it and you can get it from the gcc project
>easily enough.
Heh, no, it's us users who'd be using it (with all that implies O:-) )
>The main problem is that Apple's own C++ stuff is based on either a
>pre-C++
On Tue, Apr 14, 2015 at 9:54 AM, René J.V. wrote:
> It's a pity they don't even provide the source code for such a libstdc++
> version
Why would they? They don't use it and you can get it from the gcc project
easily enough.
The main problem is that Apple's own C++ stuff is based on either a
pr
On Tuesday April 14 2015 08:56:48 Brandon Allbery wrote:
>> would you not use libstdc++, if it works *and* can be used -- together
>> with GCC -- to compile C++11 code?
>
>
>Last I checked, it doesn't work; Apple does not and will not ship a
>libstdc++ that is C++11-compatible, because all such ar
On Tue, Apr 14, 2015 at 2:18 AM, Mihai Moldovan wrote:
> This by itself is not pulling in anything yet. What I wanted to express
> is that I assume using libstdc++ on >= 10.9 an error and using libc++ on
> <= 10.8 an error.
>
10.7 supports libc++.
Why
> would you not use libstdc++, if it works
BTW, another approach to allow a more centralised management of patches (and
probably other stuff) would be to support multiple ports in the same port dir.
That's not currently possible, is it?
> Rather than copying, you could also use symlinks, but I'd still argue that's
> a bad idea...
Actual
On Tuesday April 14 2015 13:11:58 Clemens Lang wrote:
Hi,
> Rather than copying, you could also use symlinks, but I'd still argue that's a
> bad idea...
I think one can argue just as easily that it's not a good idea NOT to keep all
patches pertaining to a given source collection in a single pl
Hi,
- On 14 Apr, 2015, at 12:46, René J.V. Bertin rjvber...@gmail.com wrote:
> It would be nice if one could bundle all patches required for that single
> source
> archive with the main port, rather than distribute (or even copy) them
> over/among the various other ports that build from that
Hi,
A bit of an unorthodox thought:
There are ports that expose different elements built from a single source
archive, typically installed through a main port on which those ports depend.
The typical approach would see those ports created as subports of said main
port, but that can lead to an
On Apr 13, 2015, at 9:38 AM, Mihai Moldovan wrote:
> On 13.04.2015 12:17 PM, Ryan Schmidt wrote:
>
>> On Apr 12, 2015, at 10:29 PM, io...@macports.org wrote:
>>
>>> Revision
>>> 135005
>>> Author
>>> io...@macports.org
>>> Date
>>> 2015-04-12 20:29:57 -0700 (Sun, 12 Apr 2015)
>>> Log Message
>>
> On Apr 14, 2015, at 00:11, Mojca Miklavec wrote:
>
> On Tue, Apr 14, 2015 at 8:18 AM, Mihai Moldovan wrote:
>> On 14.04.2015 07:44 AM, Mojca Miklavec wrote:
>>> On Tue, Apr 14, 2015 at 3:54 AM, Mihai Moldovan wrote:
>>> Could something like that be added to the compiler_blacklist
>>> PortGroup
On Tue, Apr 14, 2015 at 8:18 AM, Mihai Moldovan wrote:
> On 14.04.2015 07:44 AM, Mojca Miklavec wrote:
>> On Tue, Apr 14, 2015 at 3:54 AM, Mihai Moldovan wrote:
>> Could something like that be added to the compiler_blacklist
>> PortGroup? I believe that pure C++11 projects need consistent handling
25 matches
Mail list logo
