Hi Mojca - Fortran and Python aren't generally the easiest mix. NumPy
and SciPy struggle with them, too. Some projects provide a reasonable
configuration or setup interface into which one can specify a specific
compiler for CC, CXX, F90, FF, whatever & their *FLAGS too; some don't.
I haven't looked
As a PS: something that might make sense is to provide the qmake portgroups
with an "out_of_source" option like the cmake portgroup has. I'm not sure to
what extent all qmake versions and qmake-based projects have sufficient support
for that (QtWebengine doesn't support it, for instance), but su
Hi René,
On 27 Jun 2015, at 09:36 , René J.V. Bertin wrote:
> The {c,q}make portgroups redefine the default build system, so including
> either of them with the qt5 portgroup isn't appropriate
ok, good to know! That’s why I am asking here. :)
Thanks,
Marko
_
On Saturday June 27 2015 11:59:21 Davide Liessi wrote:
Hi,
>do you mean that any port depending on Qt or PyQt should use the qt4
>or qt5 PortGroup?
>If so, why?
Indeed. For 2 reasons:
- it declares the dependency on the Qt port in an appropriate way that allows
the user to install any port that
Hi René,
2015-06-27 9:36 GMT+02:00 René J.V. :
> that portgroup should also be usable just to record a dependency on Qt for
> applications that use neither cmake nor qmake (ports using py-qt for
> instance?).
do you mean that any port depending on Qt or PyQt should use the qt4
or qt5 PortGroup?
On 2015-6-26 08:46 , Mihai Moldovan wrote:
> We cannot easily clean distfiles, because ports may still depend on them and
> the
> original master site may be either long gone or the original tarball deleted
> for
> other reasons. That's why the distfiles are stockpiling without any cleanup.
It's
On Saturday June 27 2015 01:49:46 Marko Käning wrote:
>Hi Marcus,
>
>I wondered whether port group “qt5” should also include port group “cmake”
>since it is internally making use of it anyways?!
What makes you think that? It's not the case AFAIK. Qt5 provides both its own
qmake system and a bunch
