Re: Choice of compiler from compiler.whitelist

[Mojca Miklavec]

One more question: does
compiler.whitelist macports-gcc-6 macports-gcc-5 macports-gcc-4.9 ...
automatically add a runtime dependency on libgcc?

I just started wondering how building a port on a builtbot might
influence the user that just happens to have no gcc installed.

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Choice of compiler from compiler.whitelist

[Joshua Root]

On 2016-7-22 04:39 , Ryan Schmidt wrote:


On Jul 21, 2016, at 12:15 PM, Mojca Miklavec wrote:


The "problem" is that MacPorts seems to always take gcc 6 then, even
if I have gcc 5 already installed, but not the gcc 6.

What am I missing here? Couldn't MP take any compiler from the list?


As I understand it, if compiler.whitelist is set, MacPorts uses the first entry 
in compiler.whitelist that's not blacklisted.


Not quite -- it uses the first such compiler that is available on the 
system. Compilers provided by a port are always considered to be 
available, so this only makes a difference when Xcode-provided compilers 
are involved.



And if compiler.whitelist is not set, MacPorts uses the first entry in 
compiler.fallback that's not blacklisted. (As such, I'm not sure why 
compiler.whitelist exists; couldn't a port just as easily set compiler.fallback 
instead?)


Technically it's probably redundant, yes. But it seemed more clear to 
have a different option name to indicate that these compilers and only 
these compilers will work.



In any case, no attempt is currently made by MacPorts to check which of those 
compilers you might already have installed.


It would be possible to change that, but it would mean going from a 
simple algorithm of grabbing the first usable one from a list, to a much 
more complicated method of sorting the different possibilities according 
to multiple criteria and using the "best" one.


- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Choice of compiler from compiler.whitelist

[Ryan Schmidt]

On Jul 21, 2016, at 12:15 PM, Mojca Miklavec wrote:

> What's the best way to blacklist all clang compilers and any old gcc?
> (It's about a temporary bug mentioned in the other topic.)
> 
> 
> Here's my attempt:
> 
> PortGroup   compiler_blacklist_versions 1.0
> 
> # blacklist any clang compiler and any old gcc (a better expression is needed)
> compiler.blacklist *clang* *llvm-gcc* *apple-gcc* gcc gcc-3.3 gcc-4.0 gcc-4.2
> compiler.whitelist macports-gcc-6 macports-gcc-5 macports-gcc-4.9
> macports-gcc-4.8 macports-gcc-4.7

Looks ok.


> The "problem" is that MacPorts seems to always take gcc 6 then, even
> if I have gcc 5 already installed, but not the gcc 6.
> 
> What am I missing here? Couldn't MP take any compiler from the list?

As I understand it, if compiler.whitelist is set, MacPorts uses the first entry 
in compiler.whitelist that's not blacklisted. And if compiler.whitelist is not 
set, MacPorts uses the first entry in compiler.fallback that's not blacklisted. 
(As such, I'm not sure why compiler.whitelist exists; couldn't a port just as 
easily set compiler.fallback instead?) In any case, no attempt is currently 
made by MacPorts to check which of those compilers you might already have 
installed.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Rev bumping mpi dependents

[Sean Farley]

Joshua Root  writes:

> On 2016-7-21 09:24 , Brandon Allbery wrote:
>> On Wed, Jul 20, 2016 at 7:21 PM, Sean Farley > > wrote:
>>
>> OpenMPI just released 2.0 which will change the name of the libraries.
>> I'm guessing I should revbump all the dependents to force a rebuild but
>> is this something that `port rev-upgrade` should handle?
>>
>>
>> I think you can get into trouble with the automatic rev-upgrade catching
>> it, if it causes an upgrade for other reasons to fail? At the very least
>> it could be inefficient by causing multiple rounds of rebuilding
>> triggered during the rev-upgrade at the end of a normal upgrade.
>
> The biggest reason to rev bump is that if you don't, the archives are 
> useless. They get downloaded and installed, then rev-upgrade immediately 
> detects that the linking is broken and rebuilds from source.

Ah, of course, good point.

> If the original question was about whether the rev bumping should be 
> automated, well, maybe. We could certainly run rev-upgrade in report 
> mode on all a port's dependents after it is updated. Do we then want the 
> system automatically committing a rev bump? I'm not so sure. It might be 
> better to just email a warning to the maintainers.

One day, I'd like bots that try to update a port automatically and send
the patch to the maintainers. Hopefully, this would include rev bumping
but that's a far off dream right now.

> A concept of an archive revision as distinct from a port revision might 
> be useful here.

Yeah, that's not a bad idea either.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Choice of compiler from compiler.whitelist

[Mojca Miklavec]

Hi,

What's the best way to blacklist all clang compilers and any old gcc?
(It's about a temporary bug mentioned in the other topic.)


Here's my attempt:

PortGroup   compiler_blacklist_versions 1.0

# blacklist any clang compiler and any old gcc (a better expression is needed)
compiler.blacklist *clang* *llvm-gcc* *apple-gcc* gcc gcc-3.3 gcc-4.0 gcc-4.2
compiler.whitelist macports-gcc-6 macports-gcc-5 macports-gcc-4.9
macports-gcc-4.8 macports-gcc-4.7


The "problem" is that MacPorts seems to always take gcc 6 then, even
if I have gcc 5 already installed, but not the gcc 6.

What am I missing here? Couldn't MP take any compiler from the list?

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Compiler bug?

[Mojca Miklavec]

Reposting the question ...

On 17 July 2016 at 14:18, Mojca Miklavec wrote:
> Hi,
>
> I am unable to compile lilypond 2.19.45 (the problem must have started
> at around 2.19.42 or 43).
>
> One of the developers came up with the following minimal example (from
> the source code that Lilypond is using) that works with g++, but fails
> with clang++:
>
>
> class A {
> public:
>   template 
>   void zip () { }
>   void fun () { }
> };
>
> class B : public A
> {
> public:
>   using A::zip; // Fails to involve A::zip in overloading resolution
>   template 
>   void zip () { }
> } bex;
>
>
> void x ()
> {
>   bex.zip <&B::fun> ();
> }
>
>
> Can someone with a deeper insight into C++ please clarify if this is a
> compiler bug or just something that gcc is happy with even if it's not
> according to the standard?
>
> He suggested to compile lilypond with GCC, but lilypond has lots of
> dependencies and I'm not sure if stdlib (non-)compatibility would play
> a role or not.
>
> Thank you,
> Mojca

I just wanted to add that I successfully compiled the (pre-)latest
version of lilypond-devel (2.19.44) with gcc 5 and it seems to work.
Perhaps it doesn't have any dependencies with C++ api.

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev