Re: Branching for 2.4

[Joshua Root]

OK, so *now* are we ready to branch for 2.4? :)

- Josh

Re: science/lalinference: update to 1.8.2

[Adam Mercer]

On Sat, Jan 7, 2017 at 6:04 AM, Joshua Root  wrote:

>> 
>>
>>
>> This also reverted
>>
>> ,
>> which really is necessary. In general because you don't control the
>> value of $frameworks_dir, and it could contain characters which have
>> special meaning in a regex, and because string replacement on a Tcl list
>> is hard enough to get right. And specifically because in MacPorts 2.4 we
>> will once again be setting prefix to '${prefix}' while building the
>> PortIndex (the code that does that was accidentally non-functional in
>> 2.3).

Thanks for pointing that out, I'll get that change back in place. This
change was dropped due to the way we currently managed these ports, we
develop them out of a different repository and then when they're ready
we just copy them to the MacPorts git reposiry and commit. We really
need to find a more sane way as things like this are bound to happen
again.

It also sounds like a similar change should be made to the other lal* ports.

> Although I see I also made a typo; sorry about that. The dollar sign should
> be in front of the first brace on line 121, not in front of the bracket.

I assume you mean the following:

diff --git a/science/lalinference/Portfile b/science/lalinference/Portfile
index 018a9d96ed..f92ad99bbb 100644
--- a/science/lalinference/Portfile
+++ b/science/lalinference/Portfile
@@ -118,7 +118,7 @@ foreach v {27 34 35} {
 depends_lib-replace   port:lal port:py${v}-lal
 depends_lib-appendport:${name} port:py${v}-numpy

-configure.args-strsed s|$[quotemeta
{default_pythonarg}]|PYTHON=[quotemeta
${pythonhome}/bin/python${pythonversion}]|
+configure.args-strsed s|[quotemeta
${default_pythonarg}]|PYTHON=[quotemeta
${pythonhome}/bin/python${pythonversion}]|
 configure.args-replace --disable-python --enable-python
 configure.args-append --enable-swig-python

Cheers

Adam

Re: adding a supported compiler

[René J . V . Bertin]

On Saturday January 7 2017 06:36:26 Ryan Schmidt wrote:

>portconfigure.tcl

Thanks. Looks like a bit of monks' work to add it the right way :)

BTW, how good is the base clang driver at determining the language type from 
extension or syntax? IOW, can I use a single clazy wrapper that invokes 
clang-mp-x.y or do I absolutely need to use clang++-mp-x.y for C++ and ObjC++?

An example where being able to get advanced diagnostics from a user's machine 
*might* come in useful:
https://bugs.kde.org/show_bug.cgi?id=374568

R.

Re: science/lalinference: update to 1.8.2

[Joshua Root]

On 2017-1-8 00:00 , Joshua Root wrote:




This also reverted
,
which really is necessary. In general because you don't control the
value of $frameworks_dir, and it could contain characters which have
special meaning in a regex, and because string replacement on a Tcl list
is hard enough to get right. And specifically because in MacPorts 2.4 we
will once again be setting prefix to '${prefix}' while building the
PortIndex (the code that does that was accidentally non-functional in 2.3).


Although I see I also made a typo; sorry about that. The dollar sign 
should be in front of the first brace on line 121, not in front of the 
bracket.


- Josh

Re: adding a supported compiler

[Ryan Schmidt]

> On Jan 7, 2017, at 05:23, René J.V. Bertin  wrote:
> 
> Morning!
> 
> I've created a port for clazy (https://github.com/KDE/clazy) which provides 
> an additional layer of code analysis on top of what clang already can do.
> 
> This is a compiler wrapper, so it can be used in a normal build cycle to get 
> additional diagnostics while building code. I'd like to be able therefore to 
> do something like `configure.compiler=clazy-3.9` for certain of my projects, 
> at least locally.
> 
> Where would I make the necessary changes to make that possible?

portconfigure.tcl

adding a supported compiler

[René J . V . Bertin]

Morning!

I've created a port for clazy (https://github.com/KDE/clazy) which provides an 
additional layer of code analysis on top of what clang already can do.

This is a compiler wrapper, so it can be used in a normal build cycle to get 
additional diagnostics while building code. I'd like to be able therefore to do 
something like `configure.compiler=clazy-3.9` for certain of my projects, at 
least locally.

Where would I make the necessary changes to make that possible?

Thanks,
R.