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 extras. Many of them
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
> hand what options need t
> 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 people want, and just
>> go with that.
>
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 do users know what functionality they
Hi,
> On 12 Apr 2016, at 7:56 pm, Daniel J. Luke wrote:
>
> On Apr 12, 2016, at 2:52 PM, Christopher Jones
> wrote:
Some of them create additional libraries for the new features, some just
add the functionality to existing ones. Most will also extend the
introspection system a
On Apr 12, 2016, at 2:52 PM, Christopher Jones wrote:
>>> Some of them create additional libraries for the new features, some just
>>> add the functionality to existing ones. Most will also extend the
>>> introspection system as part of root. None can be built as afterthoughts.
>>> You have to
> 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 these
>> as optional extras. M
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 force on all
> us
> On 12 Apr 2016, at 4:59 pm, Daniel J. Luke wrote:
>
> 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 p
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’t care the
13 matches
Mail list logo
