> On May 19, 2016, at 10:23 AM, René J.V. Bertin wrote:
>
> On Thursday May 19 2016 10:09:05 Ryan Schmidt wrote:
>
>> The description I provided in quotation marks above is what the path:-based
>> dependency feature is intended to do. What you perceive is not a bug because
>> the feature was
On Thursday May 19 2016 10:09:05 Ryan Schmidt wrote:
>The description I provided in quotation marks above is what the path:-based
>dependency feature is intended to do. What you perceive is not a bug because
>the feature was not intended to do what you describe.
I've never condoned that kind of
On May 19, 2016, at 10:04 AM, René J.V. Bertin wrote:
> On Thursday May 19 2016 09:39:58 Ryan Schmidt wrote:
>
>> That's not what path:-style dependencies are for, and they don't work like
>> that. A "path:foo:bar" dependency means "if the file at path foo does not
>> exist, install the port b
On Thursday May 19 2016 09:39:58 Ryan Schmidt wrote:
>That's not what path:-style dependencies are for, and they don't work like
>that. A "path:foo:bar" dependency means "if the file at path foo does not
>exist, install the port bar, which shall provide the file at path foo". It
>will not reins
On May 19, 2016, at 9:35 AM, René J.V. Bertin wrote:
>
> On Thursday May 19 2016 09:13:11 Ryan Schmidt wrote:
>
>> We can't use variants for reasons already explained.
>>
>> You talked about using path:-style dependencies, which one only does if
>> there are multiple ports that can provide a f
On Thursday May 19 2016 09:13:11 Ryan Schmidt wrote:
>We can't use variants for reasons already explained.
>
>You talked about using path:-style dependencies, which one only does if there
>are multiple ports that can provide a file.
I don't agree: they could also be used in the context of a port
> On May 19, 2016, at 9:11 AM, René J.V. Bertin wrote:
>
> On Thursday May 19 2016 08:13:26 Ryan Schmidt wrote:
>>> Skipping those components gives me a destroot directory that is 185Mb big,
>>> as opposed to the 359Mb from the binary package for 10.9 . I must add that
>>> I build with optflag
On Thursday May 19 2016 08:13:26 Ryan Schmidt wrote:
>> Skipping those components gives me a destroot directory that is 185Mb big,
>> as opposed to the 359Mb from the binary package for 10.9 . I must add that I
>> build with optflags="-Os -march=core2", though; -Os overriding GCC's default
>> -O
> On May 19, 2016, at 7:51 AM, René J.V. Bertin wrote:
>
> On Thursday May 19 2016 11:22:35 René J.V. Bertin wrote:
>
>> So it seems that the only feasible things are skipping the ObjC and/or
>> ObjC++ compilers, and the Java compiler. I'll try to round up my "little"
>> experiment to assess
On 19/05/16 13:51, René J.V. Bertin wrote:
On Thursday May 19 2016 11:22:35 René J.V. Bertin wrote:
So it seems that the only feasible things are skipping the ObjC and/or ObjC++ compilers,
and the Java compiler. I'll try to round up my "little" experiment to assess if
that makes a lot of di
On Thursday May 19 2016 11:22:35 René J.V. Bertin wrote:
>So it seems that the only feasible things are skipping the ObjC and/or ObjC++
>compilers, and the Java compiler. I'll try to round up my "little" experiment
>to assess if that makes a lot of difference in installation footprint.
Skipping
On Wednesday May 18 2016 12:28:47 Ryan Schmidt wrote:
>Naturally a hypothetical gcc6 port that only provides a Fortran compiler would
>take less space and less time to build than one that also provides C, C++, and
>Java compilers. But then other ports that expect C, C++ or Java compilers to
>ex
I have an unfounded opinion about this:
> Naturally a hypothetical gcc6 port that only provides a Fortran compiler
> would take less space and less time to build than one that also provides C,
> C++, and Java compilers.
I’m not an expert on this at all, but from what I understand the only
lan
> On May 17, 2016, at 6:07 AM, René J.V. Bertin wrote:
>
> On a related note: would it be very hard to set up the gcc port(s) such that
> users can indicate which languages they wish to use the compiler for? IIRC
> gcc's configure script allows you to do just that via an option that receives
On Tuesday May 17 2016 13:20:22 Clemens Lang wrote:
hi,
>Have you checked with upstream? Maybe the only thing missing is a patch that
>provides a -stdlib option with a couple of defaults?
Not yet, but if it were so simple you'd think that patch would have been added
already. It's not like the is
Hi,
- On 17 May, 2016, at 13:07, René J.V. Bertin rjvber...@gmail.com wrote:
>>integration you get with clang++ -stdlib=libstdc++, though. See
>>http://stackoverflow.com/questions/8208/using-g-with-libc.
>>
>>You may want to work with upstream to improve on this.
>
> I'm acting as the vo
On Tuesday May 17 2016 12:01:15 Clemens Lang wrote:
Hi,
>There is a way to call g++ so that it uses libc++. That's not the same level of
Good to know, but if there's still a risk of having to jump through all kinds
of hoops I think I'll hold off :)
>integration you get with clang++ -stdlib=lib
Hi,
- On 17 May, 2016, at 11:43, René J.V. Bertin rjvber...@gmail.com wrote:
> I'm seeing what seem to be rave reviews about GCC 6, and also that there's a
> port for it.
>
> I guess the situation with libstdc++ vs. libc++ hasn't changed, or has someone
>
Hi,
I'm seeing what seem to be rave reviews about GCC 6, and also that there's a
port for it.
I guess the situation with libstdc++ vs. libc++ hasn't changed, or has someone
managed to get GCC to use libc++ (like clang uses libstdc+
19 matches
Mail list logo
