Re: pkg-config v. -I/opt/local/include

[Craig Treleaven]

> On Jan 13, 2016, at 2:19 AM, Ryan Schmidt  wrote:
> 
> On Jan 12, 2016, at 1:05 PM, Craig Treleaven wrote:
>> On Jan 12, 2016, at 4:09 AM, Ryan Schmidt wrote:
>>> On Jan 11, 2016, at 9:03 AM, Craig Treleaven wrote:
 I’m having buiild failures due to includes pointing to old/other headers 
 installed in /opt/local/include.
 
 As I understand it, 'pig-config —cflags’ returns an empty string when a 
 header is installed in /usr/include.  The port I’m working on, MythTV 
 0.28-pre, uses pkg-config to check for several dependencies.  Under 
 MacPorts, I end up with '-I/opt/local/include’ early in the compiler 
 arguments and thus picks up old or unintended versions of headers.  Under 
 Linux, no problem.
 
 Is there some way I can coerce pkg-config to treat /opt/local/include like 
 it does /usr/include?  I’ve looked at the man page for pkg-config and 
 tried using some of the environment variables but without success.
 
 Eg, with MacPorts:
 $ pkg-config --cflags x264
 -I/opt/local/include ## want to make this disappear!
 
 is there a magic recipe?
>>> 
>>> You should not want to make -I/opt/local/include disappear. It is where the 
>>> headers of dependencies are installed, so it is needed. If it is causing 
>>> problems, it is likely because your project's build system does not place 
>>> the include flags in the correct order. The correct order is (relative) 
>>> project include paths first, (absolute) dependency include paths second. If 
>>> you cannot fix the build system to do that, you can use your sed trick to 
>>> replace -I/opt/local/include with -isystem/opt/local/include which will 
>>> have the same effect.
>>> 
>> 
>> Hi Ryan:
>> 
>> I asked over on the pkg-config mailing list and got:
>> 
>>> This isn't documented (should be), but you can override pkg-config's notion 
>>> of the system include path with the environment variable 
>>> PKG_CONFIG_SYSTEM_INCLUDE_PATH. If that's not set, it uses the compiled in 
>>> defaults. That's been in pkg-config for a long time, so it should work with 
>>> the version you have. This should be in the form of a path style variable 
>>> with : separators.
> 
> I didn't know about that variable. Thanks for finding out about that.
> 
> 
>> This is exactly what I wanted:
>> 
>> $ pkg-config --cflags-only-I libass
>> -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include 
>> -I/opt/local/include/libpng16 -I/opt/local/include 
>> -I/opt/local/include/fribidi -I/opt/local/include/glib-2.0 
>> -I/opt/local/lib/glib-2.0/include -I/opt/local/include 
>> -I/opt/local/include/freetype2 
>> 
>> $ PKG_CONFIG_SYSTEM_INCLUDE_PATH=/opt/local/include pkg-config 
>> --cflags-only-I libass
>> -I/opt/local/include/freetype2 -I/opt/local/include/libpng16 
>> -I/opt/local/include/fribidi -I/opt/local/include/glib-2.0 
>> -I/opt/local/lib/glib-2.0/include -I/opt/local/include/freetype2 
>> 
>> Adding 'configure.env-append
>> PKG_CONFIG_SYSTEM_INCLUDE_PATH=${prefix}/include’  makes the MythTV build 
>> work the way it does on Linux (aka “successfully”).
> 
> But is that because -I/opt/local/include then gets inserted into the correct 
> place in the compile line, or because -I/opt/local/include is omitted from 
> the compile line and it only works because MacPorts also happens to set 
> CPATH=/opt/local/include and you're using a newer compiler that supports 
> that? (Granted, only very old versions of clang don't support CPATH.)

There is no '-I/opt/local/include' anywhere in my compiler args now so I assume 
CPATH is used.  

BTW, you made me curious.  A recent Fedora23 compile log from a Myth’s buildbot 
is at:

https://code.mythtv.org/buildbot/builders/master-f23-64bit/builds/104/steps/compile%20core/logs/stdio

If you search for “-I/usr/include “, the only hits are invocations of Qt’s mod! 
 Never appears in the compiler args.  So I’m now building the “Myth-blessed” 
way!  ;)

> 
>> As to whether this is the “right” thing to do, you have far more knowledge 
>> and experience than me.  I think Myth’s configure is relying on a quirk of 
>> pkg-config.  I would think that other folks that are cross-compiling--or 
>> even just using a different prefix—must be hitting this problem.  I get very 
>> little traction with the Myth devs.  They writeoff stuff like this as a 
>> “MacPorts problem”.
> 
> Yeah they would be incorrect to blame bugs in their build system on us just 
> because we use their build system in a slightly different way than they 
> apparently do.

Agreed.

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

Re: r143478 -- gsl: update version 2.0->2.1

[Takeshi Enomoto]

Hi,

It seems that the update to gsl-2.x broke fgsl (#50295), which is compatible 
with 1.16.
We may need gsl116 until the updates are provided by the upstream.

Regards,

Takeshi

-
Takeshi Enomoto
take...@macports.org

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

Re: [KDE/Mac] KDE4/KF5 "cohabitation"

[René J . V . Bertin]

On Wednesday January 13 2016 10:53:49 Jeremy Whiting wrote:

> Yes exactly, once an application has been released based on Qt5/KF5 it
> shouldn't be coinstallable with the same application that is
> Qt4/kdelibs4 based. Most (and eventually all) kf5 based applications

Shouldn't, or isn't expected to be?

> any settings. Also both kdelibs4 based and kf5 based binaries, shared
> data files etc would conflict if both were installed at once.

The binaries are mostly not an issue under MacPorts, the shared files sometimes 
a bit more, like for icon files.
But I currently have both Kate4 and Kate5, KDevelop4 and KDevelop5 installed, 
idem for Kompare and Konsole (the latter is basically unusable but because of 
issues in Qt).

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

Re: [KDE/Mac] KDE4/KF5 "cohabitation"

[Jeremy Whiting]

Yeah, not expected to be. If they are that's a bonus I guess, but not expected.

On Wed, Jan 13, 2016 at 2:05 PM, René J.V.  wrote:
> On Wednesday January 13 2016 10:53:49 Jeremy Whiting wrote:
>
>> Yes exactly, once an application has been released based on Qt5/KF5 it
>> shouldn't be coinstallable with the same application that is
>> Qt4/kdelibs4 based. Most (and eventually all) kf5 based applications
>
> Shouldn't, or isn't expected to be?
>
>> any settings. Also both kdelibs4 based and kf5 based binaries, shared
>> data files etc would conflict if both were installed at once.
>
> The binaries are mostly not an issue under MacPorts, the shared files 
> sometimes a bit more, like for icon files.
> But I currently have both Kate4 and Kate5, KDevelop4 and KDevelop5 installed, 
> idem for Kompare and Konsole (the latter is basically unusable but because of 
> issues in Qt).
>
> R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

[144621] trunk/dports/python/py-numpy/Portfile

[Joshua Root]

> Revision: 144621
>   https://trac.macports.org/changeset/144621
> Author:   sean at macports.org
> Date: 2016-01-13 23:29:24 -0800 (Wed, 13 Jan 2016)
> Log Message:
> ---
> py-numpy: numpy needs fortran, so require it

We've been through this before; numpy does not need fortran, its fortran
support is optional.

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

Re: r143478 -- gsl: update version 2.0->2.1

[David Evans]

On 1/13/16 5:48 AM, Takeshi Enomoto wrote:
> Hi,
> 
> It seems that the update to gsl-2.x broke fgsl (#50295), which is compatible 
> with 1.16.
> We may need gsl116 until the updates are provided by the upstream.
> 
> Regards,
> 
> Takeshi
> 
> -
> Takeshi Enomoto
> take...@macports.org
> 
> 

Takeshi --

I see that this has been a known issue upstream for a while[1] and that they 
have an updated version of fgsl in a
development branch that has been reported to work with gsl2[2].  Just hasn't 
been merged yet.  So maybe the upstream
solution isn't too far away.  Have you tried building from the development 
branch to see if it really works?

[1] https://github.com/reinh-bader/fgsl/issues/3
[2] https://github.com/tschoonj/fgsl/tree/gsl-2

Dave


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

Re: KDE4/KF5 "cohabitation"

[nicos]

Hello, 

> I'm sure you've noticed that I'm making progress with ports for KF5. Maybe I 
> should have asked your opinion on how to approach this (if so, apologies that 
> I didn't), but I would like to know your thoughts on the issue of 
> co-existence of KDE4 and KF5 ports.

Yes, I saw the tickets you posted, and was meaning to answer for some time, but 
got swamped in other things. Furthermore, my very small knowledge of KF5 means 
that I am not able to provide detailed answers.

> KF5 is designed to allow for step-by-step migration of applications from KDE4 
> to KDE5, but with the underlying idea that once an application has been 
> migrated it's the better version and users are not supposed to feel the need 
> to keep the older version around.
> 
> I have some issues with that premise and know of nothing in MacPorts that 
> would make it the default behaviour to force a choice between either KDE4 or 
> KF5 versions of an application (fortunately, with all the inter-dependencies).

I agree that it would very appreciable to be able to install the core package 
of both KDE4 and KF5, in order to enable the installation of applications from 
both systems, in particular as several of the applications would not be yet 
ported to KF5, while others could still be better in their KF5 form. 
However, I imagine that wanting to make the whole installation in parallel 
could be much more difficult, and that the same application with its KDE4 and 
KF5 versions would conflict in several ways, as it would intend to install the 
same binaries.

It is not clear to me at this point what aim you have. Are you aiming for full 
install (including applications) in parallel, or for non-conflicting core 
packages so that different applications from both KDE4 and KF5 could be 
installed ?

> KF5 software doesn't leave a lot of leeway to configure it such that it won't 
> clash with KDE4 versions of the same, in line with said premise. Fortunately 
> most of the time the conflicts are limited to non-crucial things in 
> ${prefix}/share, usually even things that were not changed w.r.t. their KDE4 
> version. So most of the time, the +kde4compat variant of a KF5 ports just 
> omits files that are already installed by the KDE4 version of the port.

Does this means that executables and libraries are not conflicting? I would 
have expected them to clash with identical names.
> 
> There are however certain modifications that have to be made to (certain) 
> KDE4 ports:
> 
> - The most frequent conflict occurs at the level of headerfiles. This can be 
> avoided very easily by building KDELibs4 with 
> -DINCLUDE_INSTALL_DIR=${prefix}/include/KDE4 . That puts the KDELibs headers 
> under include/KDE4 but also records the path in a cmake module, so that it is 
> inherited by all dependents.
> The nice thing is that this change doesn't break binary compatibility, so I 
> have set it unconditionally in my KDE4 PortGroup; it gets applied when a port 
> is rebuilt.

Which means that independently of binary compatibility, all KDE4 Portfiles 
would have to be revbumped if the change is applied.

> - CMake modules are still an issue; I haven't yet found out a good way to 
> install them to ${prefix}/lib/cmake/KDE4 . I'm looking into simply moving the 
> files to a place outside the standard cmake include path (requiring 
> CMAKE_PREFIX_PATH to be set) ... but that will only protect against file name 
> clashes and against KF5 ports picking up cmake modules from KDE4 software :-/

> [snip

> 
> This is where I could use help from others who have KDE4 ports installed, the 
> more complicated the dependencies the better.
> There is only so much time I can devote to checking existing KDE4 ports 
> (which do not yet have a KF5 version) against the compatibility changes I've 
> been making, in addition to the time I spend developing KF5 ports.
> 
> Help could come in 2 or 3 forms:
> - install my KDE4 portgroup and port:kdelibs4. Check what effect that has on 
> your existing KDE4 ports; should be transparent. Check if that's still the 
> case after rebuilding them (supposing that works out OK). One set of ports 
> that I haven't rebuilt is akonadi/kdepimlibs,kdepim,kdepim-runtime because 
> those are a bit too crucial for me…

It seems to me that the best way to get feedback would be to commit some of the 
changes, if indeed these are harmless. On the other hand, as I am under the 
impression that it is getting possible to have KF5 somewhat working within 
Macports (did not try myself), I also think that most useful thing for the 
users base at this point would be to include KF5 to Macports’ provided ports.

Cheers, 

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

Re: pkg-config v. -I/opt/local/include

[Ryan Schmidt]

On Jan 13, 2016, at 6:37 AM, Craig Treleaven wrote:On Jan 13, 2016, at 2:19 AM, Ryan Schmidt wrote:On Jan 12, 2016, at 1:05 PM, Craig Treleaven wrote:Adding 'configure.env-append    PKG_CONFIG_SYSTEM_INCLUDE_PATH=${prefix}/include’  makes the MythTV build work the way it does on Linux (aka “successfully”).But is that because -I/opt/local/include then gets inserted into the correct place in the compile line, or because -I/opt/local/include is omitted from the compile line and it only works because MacPorts also happens to set CPATH=/opt/local/include and you're using a newer compiler that supports that? (Granted, only very old versions of clang don't support CPATH.)There is no '-I/opt/local/include' anywhere in my compiler args now so I assume CPATH is used.  I figured.BTW, you made me curious.  A recent Fedora23 compile log from a Myth’s buildbot is at:https://code.mythtv.org/buildbot/builders/master-f23-64bit/builds/104/steps/compile%20core/logs/stdioIf you search for “-I/usr/include “, the only hits are invocations of Qt’s mod!  Never appears in the compiler args.That's expected because /usr/include is a special location. Compilers know to check there automatically. They do not know to check in /opt/local/include automatically so you have to tell them to check there. The normal should-work-everywhere way to do that is by putting -I/opt/local/include into the CPPFLAGS environment variable. If that causes problems for the myth build, that is a bug in the myth build system that the myth developers should fix.So I’m now building the “Myth-blessed” way!  ;)It would be silly of them to say that it is not supported to build myth with dependencies installed in a prefix other than /usr.___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: pkg-config v. -I/opt/local/include

[Brandon Allbery]

On Wed, Jan 13, 2016 at 2:19 AM, Ryan Schmidt 
wrote:

> But is that because -I/opt/local/include then gets inserted into the
> correct place in the compile line, or because -I/opt/local/include is
> omitted from the compile line and it only works because MacPorts also
> happens to set CPATH=/opt/local/include and you're using a newer compiler
> that supports that? (Granted, only very old versions of clang don't support
> CPATH.)


Note that some Linux distributions only package very old clang.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: KDE4/KF5 "cohabitation"

[René J . V . Bertin]

On Thursday January 14 2016 00:54:59 ni...@macports.org wrote:

>It is not clear to me at this point what aim you have. Are you aiming for full 
>install (including applications) in parallel, or for non-conflicting core 
>packages so that different applications from both KDE4 and KF5 could be 
>installed ?

I'm defining that aim as I go, basically. I'm trying to allow co-installation 
of the core packages; the framework and whatever of "plasma" I'll be able to 
port. As Jeremy pointed out, that is largely possible and intended because a 
gradual transition has been foreseen so that KDE4 applications can function 
normally "under" KF5.
As to applications: I'm not convinced that there would be much interest in 
having the KDE4 and KF5 version of all applications installed. For some, like 
KDevelop this can be justified for now, but for others it is probably good 
enough to be able to have either the KDE4 or the KF5 version activated at any 
given time. And then there is KDE PIM which shouldn't even be allowed to 
co-exist: it appears that one cannot go back (without risk) after having run 
the KF5 version.
Concurrent installation of the 2 "flavours" makes sense mostly if each of the 2 
flavours has advantages that the other doesn't have.

>Which means that independently of binary compatibility, all KDE4 Portfiles 
>would have to be revbumped if the change is applied.

Yes...

>It seems to me that the best way to get feedback would be to commit some of 
>the changes, if indeed these are harmless. On the other hand, as I am under 
>the impression that it is getting possible to have KF5 somewhat working within 
>Macports (did not try myself), I also think that most useful thing for the 
>users base at this point would be to include KF5 to Macports’ provided ports.

Marko is trying out a number of KF5 ports now. It would be nice if someone else 
could check the changes I've been making to KDE4 ports for side-effects that I 
have missed.

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

Re: [144607] trunk/dports/science/octopus/Portfile

[Ryan Schmidt]

> On Jan 13, 2016, at 11:29 AM, dstru...@macports.org wrote:
> 
> Revision
> 144607
> Author
> dstru...@macports.org
> Date
> 2016-01-13 09:29:21 -0800 (Wed, 13 Jan 2016)
> Log Message
> 
> octopus: Make +accelerate the default, to save a lot of time in building 
> atlas.
> Modified Paths
> 
>   • trunk/dports/science/octopus/Portfile
> Diff
> 
> Modified: trunk/dports/science/octopus/Portfile (144606 => 144607)
> 
> --- trunk/dports/science/octopus/Portfile 2016-01-13 16:51:07 UTC (rev 
> 144606)
> +++ trunk/dports/science/octopus/Portfile 2016-01-13 17:29:21 UTC (rev 
> 144607)
> @@ -6,7 +6,7 @@
>  
>  nameoctopus
>  version 5.0.1
> -revision0
> +revision1
>  categories  science
>  platforms   darwin
>  license GPL-2+
> @@ -52,7 +52,7 @@
>  
>  default_variants +newuoa
>  if {![variant_isset accelerate] && ![variant_isset openblas]} {
> -default_variants-append +atlas
> +default_variants-append +accelerate
>  }


But there was no reason to increase the port's revision, since the user's 
existing variants will be preserved in the upgrade. Regardless whether the user 
had the atlas or accelerate or openblas variant of octupus 5.0.1_0 installed, 
they will have exactly the same variant of octopus 5.0.1_1 installed after the 
upgrade. Increasing the revision only causes lots of unnecessary rebuilding, 
for the buildbots and for users.


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

Re: [KDE/Mac] KDE4/KF5 "cohabitation"

[Jeremy Whiting]

Hey, just some suggestions.

On Wed, Jan 13, 2016 at 8:54 AM,   wrote:
> Hello,
>
>> I'm sure you've noticed that I'm making progress with ports for KF5. Maybe I 
>> should have asked your opinion on how to approach this (if so, apologies 
>> that I didn't), but I would like to know your thoughts on the issue of 
>> co-existence of KDE4 and KF5 ports.
>
> Yes, I saw the tickets you posted, and was meaning to answer for some time, 
> but got swamped in other things. Furthermore, my very small knowledge of KF5 
> means that I am not able to provide detailed answers.
>
>> KF5 is designed to allow for step-by-step migration of applications from 
>> KDE4 to KDE5, but with the underlying idea that once an application has been 
>> migrated it's the better version and users are not supposed to feel the need 
>> to keep the older version around.
>>
>> I have some issues with that premise and know of nothing in MacPorts that 
>> would make it the default behaviour to force a choice between either KDE4 or 
>> KF5 versions of an application (fortunately, with all the 
>> inter-dependencies).
>
> I agree that it would very appreciable to be able to install the core package 
> of both KDE4 and KF5, in order to enable the installation of applications 
> from both systems, in particular as several of the applications would not be 
> yet ported to KF5, while others could still be better in their KF5 form.
> However, I imagine that wanting to make the whole installation in parallel 
> could be much more difficult, and that the same application with its KDE4 and 
> KF5 versions would conflict in several ways, as it would intend to install 
> the same binaries.
>
> It is not clear to me at this point what aim you have. Are you aiming for 
> full install (including applications) in parallel, or for non-conflicting 
> core packages so that different applications from both KDE4 and KF5 could be 
> installed ?

On linux kdelibs4 libraries and headers are coinstallable (or should
be) with kf5 versions of the same libraries and headers. Qt4 and Qt5
are also coinstallable on linux since they have different names. I'm
not sure how that works on OS X but currently on linux many of the KDE
Applications in the latest release are Qt5/KF5 based, some are still
Qt4/kdelibs4 based though and will be ported over time.

Hope that helps,
Jeremy

>
>> KF5 software doesn't leave a lot of leeway to configure it such that it 
>> won't clash with KDE4 versions of the same, in line with said premise. 
>> Fortunately most of the time the conflicts are limited to non-crucial things 
>> in ${prefix}/share, usually even things that were not changed w.r.t. their 
>> KDE4 version. So most of the time, the +kde4compat variant of a KF5 ports 
>> just omits files that are already installed by the KDE4 version of the port.
>
> Does this means that executables and libraries are not conflicting? I would 
> have expected them to clash with identical names.
>>
>> There are however certain modifications that have to be made to (certain) 
>> KDE4 ports:
>>
>> - The most frequent conflict occurs at the level of headerfiles. This can be 
>> avoided very easily by building KDELibs4 with 
>> -DINCLUDE_INSTALL_DIR=${prefix}/include/KDE4 . That puts the KDELibs headers 
>> under include/KDE4 but also records the path in a cmake module, so that it 
>> is inherited by all dependents.
>> The nice thing is that this change doesn't break binary compatibility, so I 
>> have set it unconditionally in my KDE4 PortGroup; it gets applied when a 
>> port is rebuilt.
>
> Which means that independently of binary compatibility, all KDE4 Portfiles 
> would have to be revbumped if the change is applied.
>
>> - CMake modules are still an issue; I haven't yet found out a good way to 
>> install them to ${prefix}/lib/cmake/KDE4 . I'm looking into simply moving 
>> the files to a place outside the standard cmake include path (requiring 
>> CMAKE_PREFIX_PATH to be set) ... but that will only protect against file 
>> name clashes and against KF5 ports picking up cmake modules from KDE4 
>> software :-/
>
>> [snip
>
>>
>> This is where I could use help from others who have KDE4 ports installed, 
>> the more complicated the dependencies the better.
>> There is only so much time I can devote to checking existing KDE4 ports 
>> (which do not yet have a KF5 version) against the compatibility changes I've 
>> been making, in addition to the time I spend developing KF5 ports.
>>
>> Help could come in 2 or 3 forms:
>> - install my KDE4 portgroup and port:kdelibs4. Check what effect that has on 
>> your existing KDE4 ports; should be transparent. Check if that's still the 
>> case after rebuilding them (supposing that works out OK). One set of ports 
>> that I haven't rebuilt is akonadi/kdepimlibs,kdepim,kdepim-runtime because 
>> those are a bit too crucial for me…
>
> It seems to me that the best way to get feedback would be to commit some of 
> the changes, if indeed these are 

Re: [144607] trunk/dports/science/octopus/Portfile

[Ryan Schmidt]

On Jan 13, 2016, at 11:45 AM, Ryan Schmidt wrote:

> But there was no reason to increase the port's revision, since the user's 
> existing variants will be preserved in the upgrade. Regardless whether the 
> user had the atlas or accelerate or openblas variant of octupus 5.0.1_0 
> installed, they will have exactly the same variant of octopus 5.0.1_1 
> installed after the upgrade. Increasing the revision only causes lots of 
> unnecessary rebuilding, for the buildbots and for users.

I should correct myself, and say it causes unnecessary rebuilding or 
downloading and reinstalling for users. The buildbots will have to rebuild 
regardless whether the revision is changed, because the variants are changed, 
but that's fine.


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

Re: [144607] trunk/dports/science/octopus/Portfile

[David Strubbe]

Oh ok. I have seen some ports have a revision increased recently because of
a change of default variants, so I was following that, but I guess they
shouldn't have been.

David

On Wed, Jan 13, 2016 at 12:47 PM, Ryan Schmidt 
wrote:

>
> On Jan 13, 2016, at 11:45 AM, Ryan Schmidt wrote:
>
> > But there was no reason to increase the port's revision, since the
> user's existing variants will be preserved in the upgrade. Regardless
> whether the user had the atlas or accelerate or openblas variant of octupus
> 5.0.1_0 installed, they will have exactly the same variant of octopus
> 5.0.1_1 installed after the upgrade. Increasing the revision only causes
> lots of unnecessary rebuilding, for the buildbots and for users.
>
> I should correct myself, and say it causes unnecessary rebuilding or
> downloading and reinstalling for users. The buildbots will have to rebuild
> regardless whether the revision is changed, because the variants are
> changed, but that's fine.
>
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [KDE/Mac] KDE4/KF5 "cohabitation"

[Jeremy Whiting]

Yes exactly, once an application has been released based on Qt5/KF5 it
shouldn't be coinstallable with the same application that is
Qt4/kdelibs4 based. Most (and eventually all) kf5 based applications
include a settings/config migrator that migrates settings from
kdelibs4 locations to kf5 locations if the new location doesn't have
any settings. Also both kdelibs4 based and kf5 based binaries, shared
data files etc would conflict if both were installed at once.

On Wed, Jan 13, 2016 at 10:38 AM, René J.V.  wrote:
> On Thursday January 14 2016 00:54:59 ni...@macports.org wrote:
>
>>It is not clear to me at this point what aim you have. Are you aiming for 
>>full install (including applications) in parallel, or for non-conflicting 
>>core packages so that different applications from both KDE4 and KF5 could be 
>>installed ?
>
> I'm defining that aim as I go, basically. I'm trying to allow co-installation 
> of the core packages; the framework and whatever of "plasma" I'll be able to 
> port. As Jeremy pointed out, that is largely possible and intended because a 
> gradual transition has been foreseen so that KDE4 applications can function 
> normally "under" KF5.
> As to applications: I'm not convinced that there would be much interest in 
> having the KDE4 and KF5 version of all applications installed. For some, like 
> KDevelop this can be justified for now, but for others it is probably good 
> enough to be able to have either the KDE4 or the KF5 version activated at any 
> given time. And then there is KDE PIM which shouldn't even be allowed to 
> co-exist: it appears that one cannot go back (without risk) after having run 
> the KF5 version.
> Concurrent installation of the 2 "flavours" makes sense mostly if each of the 
> 2 flavours has advantages that the other doesn't have.
>
>>Which means that independently of binary compatibility, all KDE4 Portfiles 
>>would have to be revbumped if the change is applied.
>
> Yes...
>
>>It seems to me that the best way to get feedback would be to commit some of 
>>the changes, if indeed these are harmless. On the other hand, as I am under 
>>the impression that it is getting possible to have KF5 somewhat working 
>>within Macports (did not try myself), I also think that most useful thing for 
>>the users base at this point would be to include KF5 to Macports’ provided 
>>ports.
>
> Marko is trying out a number of KF5 ports now. It would be nice if someone 
> else could check the changes I've been making to KDE4 ports for side-effects 
> that I have missed.
>
> Cheers,
> René
> ___
> kde-...@kde.org
> List Information: https://mail.kde.org/mailman/listinfo/kde-mac
> KDE/Mac Information: http://community.kde.org/Mac
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev