I think that when you already have opencv+qt5+opencv
>>> installed, an automatic upgrade to opencv should behave like `port upgrade
>>> opencv`. IOW, it should maintain the active variants. Anything else is a
>>> waste of time and source of frustration.
>>
>>
ld behave like `port upgrade
> > opencv`. IOW, it should maintain the active variants. Anything else is a
> > waste of time and source of frustration.
>
> I'm not aware of any reason why that wouldn't happen. MacPorts preserves
> variants on upgrades.
And neither do I
you already have opencv+qt5+opencv installed,
> an automatic upgrade to opencv should behave like `port upgrade opencv`. IOW,
> it should maintain the active variants. Anything else is a waste of time and
> source of frustration.
I'
> >kf5-digikam-devel or not).
>
> That's what I told Marko too, but we're not talking here about the initial
> installation. I think that when you already have opencv+qt5+opencv
> installed, an automatic upgrade to opencv should behave like `port upgrade
> opencv`.
a meaningful variant for
>kf5-digikam-devel or not).
That's what I told Marko too, but we're not talking here about the initial
installation. I think that when you already have opencv+qt5+opencv installed,
an automatic upgrade to opencv should behave like `port upgrade opencv`. IOW,
i
es the active_variants portgroup to "depend" on variants of one of
> its dependencies.
>
> From our exchange:
>
> > > >> BUT that’s not all yet. Once also needs to select the +contrib
> variant,
> > > >> otherwise you have to run another loop
Hi,
Marko tells me he's been having issues with upgrading one of my KF5 ports that
uses the active_variants portgroup to "depend" on variants of one of its
dependencies.
From our exchange:
> > >> BUT that’s not all yet. Once also needs to select the +contrib variant
Hi,
Trac seems to be down for me at the moment.
I switched most of the ports to perl5.24, but there are some ports like
- cpuid
- docbook-utils
- pcsc-tools
that do just
PortGroup perl5 1.0
depends_build port:p${perl5.major}-foo
without specifying the perl version to use
> On Apr 12, 2016, at 5:41 AM, Takeshi Enomoto wrote:
>
>> The implementation I propose is: pass on default variants like for
>> user-selected variants, nothing more or less.
>
> The compiliation does not have to be avoided for variants,
> but it would be nice i
files, would require quite some extra trickery.
Given that MacPorts is rather unique with the concept of variants in general, I
find it hard to believe that solving it the same way other package managers
must solve it is impossible.
Of course, the other obvious way to fix things is for the depend
On 12 April 2016 at 20:49, Daniel J. Luke wrote:
> On Apr 12, 2016, at 1:34 PM, Christopher Jones wrote:
>> Take if you want, as a real world case, ROOT6, which I know well. It has a
>> large number of variants, because upstream’s build system offers all these
>> as optional
On Apr 12, 2016, at 4:08 PM, Christopher Jones wrote:
>> the current situation is basically the same as what upstream provides when
>> building from source.
>
> No, it is very different.
>
> reinstalling with a new set of variants is a lot easier than figuring but by
> On 12 Apr 2016, at 8:50 pm, Daniel J. Luke wrote:
>
> On Apr 12, 2016, at 3:04 PM, Christopher Jones
> wrote:
>>> How do other package managers (that don't have variants) deal with ROOT6?
>>
>> I guess they have to decide a set of options that most
On Apr 12, 2016, at 3:04 PM, Christopher Jones wrote:
>> How do other package managers (that don't have variants) deal with ROOT6?
>
> I guess they have to decide a set of options that most people want, and just
> go with that.
and we can't do that?
>> How d
; sub-ports.
>>>
>>> It would be nice if upstream could be convinced to 'fix' this.
>>
>> You’ll need to convince them (and me) first its a bug that needs fixing. I
>> don’t see it that way.
>
> How do other package managers (that don't ha
this.
>
> You’ll need to convince them (and me) first its a bug that needs fixing. I
> don’t see it that way.
How do other package managers (that don't have variants) deal with ROOT6?
How do users know what functionality they have installed when they install
ROOT6 from source?
How
> On 12 Apr 2016, at 7:49 pm, Daniel J. Luke wrote:
>
> On Apr 12, 2016, at 1:34 PM, Christopher Jones
> wrote:
>> Take if you want, as a real world case, ROOT6, which I know well. It has a
>> large number of variants, because upstream’s build system offers all thes
On Apr 12, 2016, at 1:34 PM, Christopher Jones wrote:
> Take if you want, as a real world case, ROOT6, which I know well. It has a
> large number of variants, because upstream’s build system offers all these as
> optional extras. Many of them have dependencies I do not wish to for
t +foo builds lib-A.dylib and with +foo builds
> lib-A.dylib & lib-A-foo.dylib?
Both, and all points in-between. I wasn’t really thinking of specific cases,
just in generality.
Take if you want, as a real world case, ROOT6, which I know well. It has a
large number of variants, because u
On Apr 12, 2016, at 11:49 AM, Chris Jones wrote:
> A lot of projects simply aren't built in a way that would allow that. The
> whole package (library, whatever) needs to be configured once with all the
> options, and built once. sub ports for the additional features simply aren't
> a option in
On 12/04/16 16:33, Daniel J. Luke wrote:
On Apr 12, 2016, at 8:41 AM, Takeshi Enomoto wrote:
Scientific users don’t care the internal/policy of the package manager.
What they need is a quick way to install the ports they need.
The installation should be preferably automatic.
is the problem
On Apr 12, 2016, at 8:41 AM, Takeshi Enomoto wrote:
> Scientific users don’t care the internal/policy of the package manager.
> What they need is a quick way to install the ports they need.
> The installation should be preferably automatic.
is the problem mainly fftw-3?
Is there some reason why
Hi,
> The implementation I propose is: pass on default variants like for
> user-selected variants, nothing more or less.
I agree with David.
The compiliation does not have to be avoided for variants,
but it would be nice if the default variants were proliferated.
Scientific users don’
On Apr 11, 2016, at 5:19 PM, David Strubbe wrote:
> Of course it's not a full solution, but this seems like a fairly simple
> advance that will solve some problems.
and cause other, different problems.
[why was this port installed with this variant? why didn't I get a binary
archive?]
install
On Mon, Apr 11, 2016 at 5:19 PM, David Strubbe
wrote:
> Of course it's not a full solution, but this seems like a fairly simple
> advance that will solve some problems.
Last year had a GSoC project to add a SAT-solver based dependency engine;
it has, among other things, variant support. I belie
On Mon, Apr 11, 2016 at 5:07 PM, Daniel J. Luke wrote:
> On Apr 11, 2016, at 5:02 PM, David Strubbe wrote:
> > I agree, but the question is what to do when the port does have
> variants. Consider, for example, ports with Fortran compiler variants that
> enable optional Fortran s
On Apr 11, 2016, at 5:02 PM, David Strubbe wrote:
> I agree, but the question is what to do when the port does have variants.
> Consider, for example, ports with Fortran compiler variants that enable
> optional Fortran support, such as fftw-3. The current typical situation is
>
On Mon, Apr 11, 2016 at 4:42 PM, Daniel J. Luke wrote:
>
> The ideal port has no variants (or at least has only default variants) -
> it builds with all reasonable options and people don't have to think about
> it.
>
I agree, but the question is what to do when the por
On Apr 11, 2016, at 3:29 PM, David Strubbe wrote:
> Well, that is not the current behavior if a variant is specified manually.
yes, when you enter a different command, you do get different results.
> Why do you think it would be inappropriate to do that for default variants?
Varian
Then maybe we could have an option to pass down default variants?
On Mon, Apr 11, 2016 at 4:09 PM, Bradley Giesbrecht
wrote:
> On Mon, Apr 11, 2016 at 11:47 AM, Daniel J. Luke
> wrote:
>
>> On Apr 10, 2016, at 4:01 AM, Takeshi Enomoto
>> wrote:
>> > If the
> On Mon, Apr 11, 2016 at 11:47 AM, Daniel J. Luke <mailto:dl...@geeklair.net>> wrote:
> On Apr 10, 2016, at 4:01 AM, Takeshi Enomoto <mailto:take...@macports.org>> wrote:
> > If there is a reason behind treating default_variants and manually set
> > variants
Well, that is not the current behavior if a variant is specified manually.
What happens is:
port install A +var
does
port install B +var && port install A +var.
Why do you think it would be inappropriate to do that for default variants?
On Mon, Apr 11, 2016 at 11:47 AM, Daniel J. Luk
On Apr 10, 2016, at 4:01 AM, Takeshi Enomoto wrote:
> If there is a reason behind treating default_variants and manually set
> variants,
> I’d like to know.
I'm not sure what the initial reasoning was, but I think the current behavior
is correct.
When a port is installed as a
If there is a reason behind treating default_variants and manually set variants,
I’d like to know.
If there is no reason and it can be changed, I will file a ticket for this as a
feature request.
I tried to read the MacPorts source but lost at some point...
Takeshi
-
Takeshi Enomoto
take
Add nglib and occ variants
> --+--
> Reporter: ian.rees@… | Owner: sean@…
> Type: enhancement | Status: assigned
> Priority: Normal | Milestone:
> Component: ports|Version:
> Resolution:
I'd like to second that. I think many issues of variant dependencies are
helped by passing down both manually specified and default variants.
David
On Mon, Apr 4, 2016 at 10:44 AM, Takeshi Enomoto
wrote:
> Dear Ryan and Mojca,
>
> OK. So I see that this is not the problem of
Dear Ryan and Mojca,
OK. So I see that this is not the problem of the port.
I don’t have a solution at this time,
but I hope that the manually specified variants
and default_variants should be treated equally
in the future.
Regards,
Takeshi
-
Takeshi Enomoto
take...@macports.org
On 3 April 2016 at 09:40, Takeshi Enomoto wrote:
> Hi,
>
> It seems that variants in default_variants are not proliferated as
> those specified in the command-line.
> I have this problem with some ports that I maintain and
> cause build failures with the buildbots.
>
> I
On Apr 3, 2016, at 2:40 AM, Takeshi Enomoto wrote:
> It seems that variants in default_variants are not proliferated as
> those specified in the command-line.
> I have this problem with some ports that I maintain and
> cause build failures with the buildbots.
>
> I would be h
Hi,
It seems that variants in default_variants are not proliferated as
those specified in the command-line.
I have this problem with some ports that I maintain and
cause build failures with the buildbots.
I would be helpful if you help me fix this.
Takeshi
---
Assume port A depends on port B
I'm on current trunk (r146932), and I'm running into an issue with variants
during an upgrade.
$ port list outdated
Warning: The 'list' action only shows the currently available version of each
port. To see installed versions, use the 'installed' action.
wine-de
Hi David,
- On 15 Oct, 2015, at 21:21, David Strubbe dstru...@macports.org wrote:
> Do you have a suggestion of how to accomplish that? That could potentially be
> a
> simpler approach than adding include guards.
PortGroup is a function defined in base/src/port1.0/portutil.tcl, line 2563. I
Hi Rainer,
Do you have a suggestion of how to accomplish that? That could potentially
be a simpler approach than adding include guards.
If we do go with include guards, anyone want to comment on my particular
implementation?
Index: dports/_resources/port1.0/group/active_variants-1.1.tcl
On 2015-10-14 05:49, Ryan Schmidt wrote:
> You're right, it's probably important for portgroup to guard against multiple
> inclusion.
>
> https://en.wikipedia.org/wiki/Include_guard
>
> "port lint" will warn you if you include a portgroup more than once, but that
> won't check portgroup inclusi
> On Oct 13, 2015, at 10:38 PM, David Strubbe wrote:
>
> Would something like this be a good idea to prevent multiple definition? This
> could potentially be an issue with other nested portgroups too.
>
> Index: dports/_resources/port1.0/group/active_variants-1.1.tcl
>
e executed twice?
> >
> > It isn't, two pre-activate procedures have been registered and they
> are
> > each executed once.
> >
> >
> > Well, I only put one block of code in active variants, as below. Why
> > does it end up in two different
On 2015-10-14 13:04 , David Strubbe wrote:
> > - Why is pre-activate code executed twice?
>
> It isn't, two pre-activate procedures have been registered and they are
> each executed once.
>
>
> Well, I only put one block of code in active variants, as b
re installed.
>
Ok, I think I understand. port notices that BWidget is defective in not
having its dependency tk installed (this is what you mean by "upgrading"
right?), and then fixes this by installing tk, taking into account only the
variants that BWidget was installed with (none) an
on during installation of dependencies in both
cases, but tk happens to already be installed during the upgrading of
BWidget which happens before dependencies are installed.
Wanting this to work how you want is exactly equivalent to depending on
variants, which you can't currently do.
> -
:debug:activate activate phase started at Sun Oct 11 22:00:07 EDT 2015
> :debug:activate Executing proc-pre-org.macports.activate-activate-0
> :debug:activate Found Dependency: path: /opt/local/lib/libgcc filename:
> libgcc_s.1.dylib regex: ^libgcc_s.1.dylib$
> :debug:activate Active va
Executing proc-pre-org.macports.activate-activate-0
:debug:activate Found Dependency: path: /opt/local/lib/libgcc filename:
libgcc_s.1.dylib regex: ^libgcc_s.1.dylib$
:debug:activate Active variants check for activate-type install considers
depends_lib depends_run: fftw-3 mesa libGLU tcl tk xorg-l
are suggesting it is related to the fact that tk is a
dependency of BWidget. It's hard to understand why that would matter for
what variant got passed to tk.
>
> > Regarding the pre-activate, I added this code to my copy of
> > active_variants-1.1.tcl:
> >
> > +p
installed dependencies are upgraded before new
dependencies are installed.
> Regarding the pre-activate, I added this code to my copy of
> active_variants-1.1.tcl:
>
> +pre-activate {
> +ui_warn "checking active variants"
> +_check_require_active_variants arc
http://mse.uk.packages.macports.org/sites/packages.macports.org/tk
...
Regarding the pre-activate, I added this code to my copy of
active_variants-1.1.tcl:
+pre-activate {
+ui_warn "checking active variants"
+_check_require_active_variants archivefetch
+}
When I do a fresh install, I see thi
On Oct 10, 2015, at 5:33 PM, David Strubbe wrote:
> Specifically, my recently added xcrysden port needs tk +x11 (checked via
> active_variants), whereas the default is +quartz. As of a couple of weeks
> ago, I think I was able successfully to trigger installation of tk +x11 when
> it was not i
On 2015-10-11 09:33 , David Strubbe wrote:
> Hi all,
>
> It seems to me that as of recently it was the case that variants from
> the install command line are passed on to the building of dependencies
> (as discussed below last year), but that it is no longer happening. Is
> t
Hi all,
It seems to me that as of recently it was the case that variants from the
install command line are passed on to the building of dependencies (as
discussed below last year), but that it is no longer happening. Is this
something that was changed (deliberately or otherwise) in the 2.3.4
to clang-3.{0,1,2}
>>>> respectively.
>>>
>>> Yup.
>>>
>>>> These clang ports are no obsolete.
>>>
>>> Yup.
>>>
>>>> However, there are still quite some ports around with these variants, so I
>>>> guess
On Apr 26, 2015, at 8:28 PM, Ryan Schmidt wrote:
> and that if there is are objections within a number of days
Editing error: this should have read "if there are no objections"
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://li
> Yup.
>>
>>> These clang ports are no obsolete.
>>
>> Yup.
>>
>>> However, there are still quite some ports around with these variants, so I
>>> guess these clang3{0,1,2} variants (and maybe others) should be removed?
>>
>> Yup
p.
>
>> However, there are still quite some ports around with these variants, so I
>> guess these clang3{0,1,2} variants (and maybe others) should be removed?
>
> Yup.
>
> vq
Okay,
anything else which should be considered for a "variant cleanup"?
I guess th
On Apr 25, 2015, at 5:49 AM, petr <9...@ingv.it> wrote:
> To my understanding the +clang3{0,1,2} refer to clang-3.{0,1,2} respectively.
Yup.
> These clang ports are no obsolete.
Yup.
> However, there are still quite some ports around with these variants, so I
> guess
Hi all,
To my understanding the +clang3{0,1,2} refer to clang-3.{0,1,2} respectively.
These clang ports are no obsolete.
However, there are still quite some ports around with these variants, so I
guess these clang3{0,1,2} variants (and maybe others) should be removed?
~petr
On Mar 8, 2015, at 1:39 PM, René J.V. Bertin wrote:
> Can a port have variants that it doesn't "advertise"? In other words, what
> happens if a portfile uses `variant_isset` to check whether or not a variant
> has been selected, but doesn't contain (or contains a
- On 8 Mar, 2015, at 19:39, René J.V. Bertin rjvber...@gmail.com wrote:
> Can a port have variants that it doesn't "advertise"? In other words, what
> happens if a portfile uses `variant_isset` to check whether or not a variant
> has been selected, but doesn&
Hi,
Can a port have variants that it doesn't "advertise"? In other words, what
happens if a portfile uses `variant_isset` to check whether or not a variant
has been selected, but doesn't contain (or contains a commented-out)
declaration for that variant?
Am I right that ev
efforts are to transition the portfile to explicit positive
> variants while maintaining compatible behavior; after about a year, you
> will remove the transitional code, completing the transformation to
> explicit positive variants; everything is virtually identical. Please
> correct me
Hi all,
- On 19 Feb, 2015, at 20:41, Mojca Miklavec mo...@macports.org wrote:
> Clemens, are you willing to create a ticket explaining what you wrote?
> (I don't have enough insight into the internals yet.)
Sure:
https://trac.macports.org/ticket/46956
I think this is actually pretty easy
> On Feb 19, 2015, at 2:41 PM, Mojca Miklavec wrote:
> How would you replace variants "[+]clang34 clang35 clang36 clang37"?
>"port install foo +no_clang34 +clang36"?
port install foo would be equivalent to the previous port install foo +clang34
port install f
On Thu, Feb 19, 2015 at 4:14 PM, Clemens Lang wrote:
> - On 19 Feb, 2015, at 16:02, Daniel J. Luke wrote:
>> or we could avoid default variants (and maybe go back to having +no_foo
>> variants
>> for the corner cases where someone wants to build with less function
Hi,
- On 19 Feb, 2015, at 16:02, Daniel J. Luke dl...@geeklair.net wrote:
> or we could avoid default variants (and maybe go back to having +no_foo
> variants
> for the corner cases where someone wants to build with less functionality if
> necessary).
that sounds like a st
> On Feb 19, 2015, at 10:14 AM, Clemens Lang wrote:
> - On 19 Feb, 2015, at 16:02, Daniel J. Luke dl...@geeklair.net wrote:
>> or we could avoid default variants (and maybe go back to having +no_foo
>> variants
>> for the corner cases where someone wants to build wi
> On Feb 19, 2015, at 8:17 AM, Clemens Lang wrote:
> - On 19 Feb, 2015, at 12:18, Mojca Miklavec mo...@macports.org wrote:
>> I like variants. But I believe that many of us are often bitten by the
>> inability to "get rid of" outdated variants without manual
>&
Hi,
- On 19 Feb, 2015, at 12:18, Mojca Miklavec mo...@macports.org wrote:
> I like variants. But I believe that many of us are often bitten by the
> inability to "get rid of" outdated variants without manual
> intervention.
Fully agree. We should have an additional fi
Hi,
I like variants. But I believe that many of us are often bitten by the
inability to "get rid of" outdated variants without manual
intervention.
Typical examples:
- clang-3.x keeps changing its mind about whether +analyzer /
+arm_runtime should be the default or not. When the
FYI,
I just submitted standalone tickets for variants and patches included in my
qt4-mac concurrent ticket but not related to making Qt4 co-installable :
#46606: qt4-mac "noexceptions" variant
Ticket URL: <https://trac.macports.org/ticket/46606>
#46607: qt4-mac +KDE variant.
Ti
> think the exact opposite situation might actually be more dangerous.
There were two current versions of the same port with differing variants:
---> postfix @2.11.3_0
---> postfix @2.11.3_0+dovecot_sasl+mariadb
I was surprised that "port activate postfix" asked for a
Hi,
- On 11 Dec, 2014, at 22:31, Bradley Giesbrecht pixi...@macports.org wrote:
> If installation/activation of ports via dependency ignores installed inactive
> versions I think this a bug in base.
>
> Shouldn't dependency installation take into consideration multiple inactive
> versions as
On Dec 11, 2014, at 1:06 PM, Bradley Giesbrecht wrote:
>
> On Dec 11, 2014, at 12:41 PM, Joshua Root wrote:
>
>> On 2014-12-12 06:51 , Bradley Giesbrecht wrote:
>>>
>>> On Dec 10, 2014, at 12:19 AM, Ryan Schmidt wrote:
>>>
On Dec 9, 2014, at 1:21 PM, Bradley Giesbrecht wrote:
>>>
On Dec 11, 2014, at 12:41 PM, Joshua Root wrote:
> On 2014-12-12 06:51 , Bradley Giesbrecht wrote:
>>
>> On Dec 10, 2014, at 12:19 AM, Ryan Schmidt wrote:
>>
>>>
>>> On Dec 9, 2014, at 1:21 PM, Bradley Giesbrecht wrote:
>>>
Is this behavior by design?
$ sudo port -q deactiva
On 2014-12-12 06:51 , Bradley Giesbrecht wrote:
>
> On Dec 10, 2014, at 12:19 AM, Ryan Schmidt wrote:
>
>>
>> On Dec 9, 2014, at 1:21 PM, Bradley Giesbrecht wrote:
>>
>>> Is this behavior by design?
>>>
>>> $ sudo port -q deactivate sqlgrey postfix
>>> ---> Deactivating sqlgrey @1.8.0-rc2_2+mys
On Dec 10, 2014, at 7:20 AM, Jeremy Lavergne wrote:
> On Dec 10, 2014, at 3:19 AM, Ryan Schmidt wrote:
>
>> It looks expected, in so far as you have multiple versions of postfix
>> installed, asked MacPorts to activate postfix, and did not specify which one
>> you wanted to activate.
>
> The
On Dec 10, 2014, at 12:19 AM, Ryan Schmidt wrote:
>
> On Dec 9, 2014, at 1:21 PM, Bradley Giesbrecht wrote:
>
>> Is this behavior by design?
>>
>> $ sudo port -q deactivate sqlgrey postfix
>> ---> Deactivating sqlgrey @1.8.0-rc2_2+mysql+perl5_20
>> ---> Deactivating postfix @2.11.3_0
>> $ s
On Dec 9, 2014, at 1:21 PM, Bradley Giesbrecht wrote:
> Is this behavior by design?
>
> $ sudo port -q deactivate sqlgrey postfix
> ---> Deactivating sqlgrey @1.8.0-rc2_2+mysql+perl5_20
> ---> Deactivating postfix @2.11.3_0
> $ sudo port -q activate sqlgrey postfix
> ---> Computing dependenci
Is this behavior by design?
$ sudo port -q deactivate sqlgrey postfix
---> Deactivating sqlgrey @1.8.0-rc2_2+mysql+perl5_20
---> Deactivating postfix @2.11.3_0
$ sudo port -q activate sqlgrey postfix
---> Computing dependencies for sqlgrey
---> Dependencies to be installed: postfix
---> Activ
On Nov 16, 2014, at 5:32 PM, David Strubbe wrote:
> All right, but can you clarify about default variants: is it true that
> default variants are not passed to dependencies, but all other variants are?
> And, is there any good reason for this? It would solve my problem immediately
All right, but can you clarify about default variants: is it true that
default variants are not passed to dependencies, but all other variants
are? And, is there any good reason for this? It would solve my problem
immediately if they were passed on.
On Sun, Nov 16, 2014 at 5:17 PM, Joshua Root
Asking to ensure that your dependencies have certain variants applied is
depending on variants. Restricting it to variants that the dependent
port has itself doesn't change the fundamental issues.
- Josh
On 2014-11-17 09:05 , David Strubbe wrote:
> Thanks for the comments. I'm
Thanks for the comments. I'm not trying to depend on a variant, and I am
already using active_variants (that is what blocks fftw-3 without a Fortran
variant). I just wonder why default variants are not passed to dependencies
(because other variants do seem to be passed to dependencies) and wh
On 2014-11-17 08:52 , David Strubbe wrote:
> Hi all,
>
> Is there a way to make default variants be passed to dependencies when
> installing them? My octopus port depends on fftw-3 and needs it to be
> built with a Fortran variant. octopus has +gcc48 as default variant, and
&g
On Sun, Nov 16, 2014 at 4:52 PM, David Strubbe
wrote:
> Is there a way to make default variants be passed to dependencies when
> installing them? My octopus port depends on fftw-3 and needs it to be built
> with a Fortran variant. octopus has +gcc48 as default variant, and building
Hi all,
Is there a way to make default variants be passed to dependencies when
installing them? My octopus port depends on fftw-3 and needs it to be built
with a Fortran variant. octopus has +gcc48 as default variant, and building
fftw-3 +gcc48 will work. But on the buildbots it just builds fftw
On Oct 1, 2014, at 3:30 PM, Sean Farley wrote:
> Lawrence Velázquez writes:
>
>> Except that base automatically adds dependencies on `gccXY` depending on
>> configure.compiler, so renaming them requires some sort of migration
>> strategy. Either we wait until a new MacPorts release, or we jury
umber so no change would be
>>> necessary there.
>>
>> We really should be consistent then. I personally don't care what the
>> new name is but we should either have clangX.Y / gccX.Y or clangXY /
>> gccXY.
>
> I say we use gccX.Y. Just renaming gcc port
Lawrence Velázquez writes:
> On Oct 1, 2014, at 3:08 PM, Frank Schima wrote:
>
>> On Oct 1, 2014, at 12:26 PM, Sean Farley wrote:
>>
>>> We really should be consistent then. I personally don't care what the
>>> new name is but we should either have clangX.Y / gccX.Y or clangXY /
>>> gccXY.
>>
On Oct 1, 2014, at 3:08 PM, Frank Schima wrote:
> On Oct 1, 2014, at 12:26 PM, Sean Farley wrote:
>
>> We really should be consistent then. I personally don't care what the
>> new name is but we should either have clangX.Y / gccX.Y or clangXY /
>> gccXY.
>
> I say we use gccX.Y. Just renaming
then. I personally don't care what the
> new name is but we should either have clangX.Y / gccX.Y or clangXY /
> gccXY.
I say we use gccX.Y. Just renaming gcc ports (for now) won’t be too hard.
> 2) Rename +gccXY variants to +gfortranXY
Sounds good to me, though we should use +gfo
ard new versions of gcc starting with gcc5
> will just have a single major version number so no change would be necessary
> there.
We really should be consistent then. I personally don't care what the
new name is but we should either have clangX.Y / gccX.Y or clangXY /
gccXY.
>> 2)
ion number so no change would be necessary there.
> 2) Rename +gccXY variants to +gfortranXY
Note that some ports use gcc variants not for fortran support but for java
support. I'm thinking here of my much-neglected pdftk port, though for that I
may just remove the variants and use a single
Proposal:
Since it seems that we are flat-out disallowing gcc being used as a
C/C++ compiler, I think it's time to do some clean up of the code:
1) Rename gccXY to gcc-X.Y
2) Rename +gccXY variants to +gfortranXY
3) Start moving away from configure.compiler=macports-gcc*
I think
1 - 100 of 393 matches
Mail list logo
