Fink

Daniel Macks wrote:

<snip all>
> 
> Thoughts?
> 
To put it short and please do not see this as completely useless 
critique. This is too complicated for my taste. Creating packages for 
Fink has to be as simple as humanly possible, because it enables us to 
harvest more willing package maintainers when the work they are doing 
isn't too complicated. I know that this requirement introduces a 
challenge to the actual engine behind the packages, yet we should accept 
this challenge. I know how to handle regular expression albeit I am no 
Guru with them. But you can hardly expect the majority of the Mac 
community that might be willing to learn and grow into packaging to 
learn much about regular expressions.
This is partly my personal opinion, partly an opinion as someone who 
wants to keep things simple so that we do not slide into a 
documentation, explanation, support nightmare.

-d

On Tue, Feb 10, 2004 at 02:45:59PM +0100, Darian Lanx wrote:
> Daniel Macks wrote:
> <snip all>
> >
> >Thoughts?
>
> To put it short and please do not see this as completely useless
> critique. This is too complicated for my taste. [...]  But you can
> hardly expect the majority of the Mac community that might be
> willing to learn and grow into packaging to learn much about regular
> expressions.

The simpler version of the idea is just a simple string equality test:

  Depends: (%type_perl_version 5.8.1) thing-pm
  Depends: (X%type_nox X) x11

Either tho two strings are the same (so the package is kept as a
dependency) or they are not (in which case the it is not). Although
the second example is kinda shell-ugly.

> This is partly my personal opinion, partly an opinion as someone who
> wants to keep things simple so that we do not slide into a
> documentation, explanation, support nightmare.

Makes sense. That's why I'm here looking for improvements rather than
already off wading through Fink:: :).

Thanks for the feedback,
dan

-- 
Daniel Macks
dmacks@...
http://www.netspace.org/~dmacks

On Tue, Feb 10, 2004 at 01:05:54PM -0500, Daniel Macks wrote:
> 
> The simpler version of the idea is just a simple string equality test:
> 
>   Depends: (%type_perl_version 5.8.1) thing-pm
>   Depends: (X%type_nox X) x11
> 
> Either [the two strings in parens] are the same (so the package is
> kept as a dependency) or they are not (in which case the it is not).

This syntax turned out to be not very difficult to implement. Unless
anyone has any objections to having this functionality, taking this
approach, or using this syntax...

dan

-- 
Daniel Macks
dmacks@...
http://www.netspace.org/~dmacks

Daniel Macks wrote:

> On Tue, Feb 10, 2004 at 01:05:54PM -0500, Daniel Macks wrote:
> 
>>The simpler version of the idea is just a simple string equality test:
>>
>>  Depends: (%type_perl_version 5.8.1) thing-pm
>>  Depends: (X%type_nox X) x11
>>
>>Either [the two strings in parens] are the same (so the package is
>>kept as a dependency) or they are not (in which case the it is not).
> 
> 
> This syntax turned out to be not very difficult to implement. Unless
> anyone has any objections to having this functionality, taking this
> approach, or using this syntax...

I'm not against the idea of "variants" nor "variant dependencies", but 
the syntax is very strange, there's a lot of noise.

Wouldn't it make more sense to maybe do something as a preprocessor 
stage or something like that rather than adding even more new and 
unusual syntax?

Since you can have carriage returns in depends and stuff now (at least I 
think you can) you could do:

Depends: <<
#if PERL_VERSION = 5.8.1
	thing-pm,
#endif
#ifdef X11
	foo,
#else
	foo-nox,
#endif
	bar
<<

It's still not pretty, but it at least lets people bootstrap off a lot 
of existing domain knowledge of the C preprocessor.  And we wouldn't 
even have to write anything new, we just have to call cpp with the right 
-D's for everything fink "provides" and everything is done for us.

ohhhh I like this one RangerRick.
---
TS
http://southofheaven.org
Chaos is the beginning and end, try dealing with the rest.

On 11-Feb-04, at 5:27 AM, Benjamin Reed wrote:

> Daniel Macks wrote:
>
>> On Tue, Feb 10, 2004 at 01:05:54PM -0500, Daniel Macks wrote:
>>> The simpler version of the idea is just a simple string equality 
>>> test:
>>>
>>>  Depends: (%type_perl_version 5.8.1) thing-pm
>>>  Depends: (X%type_nox X) x11
>>>
>>> Either [the two strings in parens] are the same (so the package is
>>> kept as a dependency) or they are not (in which case the it is not).
>> This syntax turned out to be not very difficult to implement. Unless
>> anyone has any objections to having this functionality, taking this
>> approach, or using this syntax...
>
> I'm not against the idea of "variants" nor "variant dependencies", but 
> the syntax is very strange, there's a lot of noise.
>
> Wouldn't it make more sense to maybe do something as a preprocessor 
> stage or something like that rather than adding even more new and 
> unusual syntax?
>
> Since you can have carriage returns in depends and stuff now (at least 
> I think you can) you could do:
>
> Depends: <<
> #if PERL_VERSION = 5.8.1
> 	thing-pm,
> #endif
> #ifdef X11
> 	foo,
> #else
> 	foo-nox,
> #endif
> 	bar
> <<
>
> It's still not pretty, but it at least lets people bootstrap off a lot 
> of existing domain knowledge of the C preprocessor.  And we wouldn't 
> even have to write anything new, we just have to call cpp with the 
> right -D's for everything fink "provides" and everything is done for 
> us.
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Fink-devel mailing list
> Fink-devel@...
> https://lists.sourceforge.net/lists/listinfo/fink-devel
>

Benjamin Reed wrote:

> Daniel Macks wrote:
> 
>> On Tue, Feb 10, 2004 at 01:05:54PM -0500, Daniel Macks wrote:
>>
>>> The simpler version of the idea is just a simple string equality test:
>>>
>>>  Depends: (%type_perl_version 5.8.1) thing-pm
> 
> Since you can have carriage returns in depends and stuff now (at least I 
> think you can) you could do:
> 
> Depends: <<
> #if PERL_VERSION = 5.8.1
>     thing-pm,
> #endif
> #ifdef X11
>     foo,
> #else
>     foo-nox,
> #endif
>     bar
> <<
> 
> It's still not pretty, but it at least lets people bootstrap off a lot 
> of existing domain knowledge of the C preprocessor.  And we wouldn't 
> even have to write anything new, we just have to call cpp with the right 
> -D's for everything fink "provides" and everything is done for us.

I prefer Daniel's method if this is a vote :)
We don't have to call some external processor which might randomly break 
(e.g. putting #pragma foo as the first line), it can all be done easily in perl.

Peter
-- 
Peter O'Gorman - http://www.pogma.com

Peter O'Gorman wrote:

> Benjamin Reed wrote:
> 
>> Daniel Macks wrote:
>>
>>> On Tue, Feb 10, 2004 at 01:05:54PM -0500, Daniel Macks wrote:
>>>
>>>> The simpler version of the idea is just a simple string equality test:
>>>>
>>>>  Depends: (%type_perl_version 5.8.1) thing-pm
>>
>>
>> Since you can have carriage returns in depends and stuff now (at least 
>> I think you can) you could do:
>>
>> Depends: <<
>> #if PERL_VERSION = 5.8.1
>>     thing-pm,
>> #endif
>> #ifdef X11
>>     foo,
>> #else
>>     foo-nox,
>> #endif
>>     bar
>> <<
>>
>> It's still not pretty, but it at least lets people bootstrap off a lot 
>> of existing domain knowledge of the C preprocessor.  And we wouldn't 
>> even have to write anything new, we just have to call cpp with the 
>> right -D's for everything fink "provides" and everything is done for us.
> 
> 
> I prefer Daniel's method if this is a vote :)
> We don't have to call some external processor which might randomly break 
> (e.g. putting #pragma foo as the first line), it can all be done easily 
> in perl.
> 
Yes, I vote for a solution in Perl as well, yet I still think that the 
syntax is simply bad. Bad as in too complicated for the common or novice 
packager to understand. Maybe we could find a syntax that is based upon 
a flow thought and not based upon an expression how the underlying 
parser can best handle it.

What does the syntax actually which to express?

Basicaly what Benjamin stated, right ?

If some condition is met use dependancy foo if not then use dependency blah.

So why not do this in the abbreviated if syntax we all know from C or 
perl which can easily be explained.


> Peter

On Wed, Feb 11, 2004 at 07:27:52AM -0500, Benjamin Reed wrote:
> 
> Wouldn't it make more sense to maybe do something as a preprocessor 
> stage or something like that rather than adding even more new and 
> unusual syntax?
> 
> Since you can have carriage returns in depends and stuff now (at least I 
> think you can) you could do:
> 
> Depends: <<
> #if PERL_VERSION = 5.8.1
> 	thing-pm,
> #endif
> #ifdef X11
> 	foo,
> #else
> 	foo-nox,
> #endif
> 	bar
> <<
> 
> It's still not pretty, but it at least lets people bootstrap off a lot 
> of existing domain knowledge of the C preprocessor.  And we wouldn't 
> even have to write anything new, we just have to call cpp with the right 
> -D's for everything fink "provides" and everything is done for us.

I thought cpp only comes with DevTools.

dan
-- 
Daniel Macks
dmacks@...
http://www.netspace.org/~dmacks

On Wed, Feb 11, 2004 at 03:47:57PM +0100, Darian Lanx wrote:
> Peter O'Gorman wrote:
> >Daniel Macks wrote:
> >>
> >
> >
> Yes, I vote for a solution in Perl as well, yet I still think that the 
> syntax is simply bad. Bad as in too complicated for the common or novice 
> packager to understand. Maybe we could find a syntax that is based upon 
> a flow thought and not based upon an expression how the underlying 
> parser can best handle it.
> 
> What does the syntax actually which to express?
> 
> Basicaly what Benjamin stated, right ?
> 
> If some condition is met use dependancy foo if not then use dependency blah.
> 
> So why not do this in the abbreviated if syntax we all know from C or 
> perl which can easily be explained.

It we want to go programming-language-style:

  Depends: %type_perl_version == 5.8.1 && thing-pm
  Depends: %type_nox == -nox || x11

It we want to be a bit more linguistic/thought-process oriented:

  Depends: %type_perl_version = 5.8.1 ? thing-pm

dan

-- 
Daniel Macks
dmacks@...
http://www.netspace.org/~dmacks

Daniel Macks wrote:

> It we want to go programming-language-style:
> 
>   Depends: %type_perl_version == 5.8.1 && thing-pm
>   Depends: %type_nox == -nox || x11
> 
> It we want to be a bit more linguistic/thought-process oriented:
> 
>   Depends: %type_perl_version = 5.8.1 ? thing-pm

Actually, I think the part that seemed most confusing to me was the 
whole "%type_perl_version" thing.  Is it a perl hash?  is it a % 
expansion?  Is it neither?  Is it a reference to some internal function, 
or just a token?  What is the significance of "type"?  It seems to be 
overloading the existing % stuff in a way that just feels weird to me.

Not that I really have a better suggestion, really, it's just that it 
makes the info files look even more busy and/or obtuse than they already do.

On Wed, Feb 11, 2004 at 02:11:19PM -0500, Benjamin Reed wrote:
> Daniel Macks wrote:
> 
> >It we want to go programming-language-style:
> >
> >  Depends: %type_perl_version == 5.8.1 && thing-pm
> >  Depends: %type_nox == -nox || x11
> >
> >It we want to be a bit more linguistic/thought-process oriented:
> >
> >  Depends: %type_perl_version = 5.8.1 ? thing-pm
> 
> Actually, I think the part that seemed most confusing to me was the 
> whole "%type_perl_version" thing. Is it a perl hash?  is it a % 
> expansion?  Is it neither?  Is it a reference to some internal function, 
> or just a token?  What is the significance of "type"?  It seems to be 
> overloading the existing % stuff in a way that just feels weird to me.

Oh! Well why didn't anybody *say* so:) That was just pseudocode.

Early in the -devel variants discussions, it was decided that we
should overload the Type: field. So we just need a way to get at that
info. If we have:

  Type: perl (5.8.0 5.8.1), x11 (-nox "")

We could have %type_perl and %type_x11, or %type[perl] and %type[x11].
The first is reminiscent of automake templates, the latter as C arrays
with constants or enums.

dan

-- 
Daniel Macks
dmacks@...
http://www.netspace.org/~dmacks

On Wed, Feb 11, 2004 at 09:35:42PM +0100, David H. wrote:
> Daniel Macks wrote:
> 
> <snip>
> Ok I will play the advocate of "easiness" now.

Bring it on.

> >Early in the -devel variants discussions, it was decided that we
> >should overload the Type: field. So we just need a way to get at that
> >info. If we have:
> 
> So why not try something like this:
> 
> Depends: perl = 5.8.1 ? bleh.pm : blah.pm
> Depends: X = yes ? x11 : nox

For the Depends logic, I think the bleh-or-blah would not be a very
common occurance. More often (at least in the situations I can think
of) is "bleh only if [something]" *or* "blah only if not [something]".
Having to conjure up a "nox" package just to make the logic work
bothers me. But if people think if/then/else is the way to go...

As to the variant value syntax, we also need to get these variant
values into Package and into *Script fields. It seems pretty confusing
that "perl" has a sepcial meaning anywhere, and I think that string
might be prone to appear in scripts so we'd need something else there.
I'd rather keep a uniform syntax everywhere in .info. Maintainers
already know about percent expansion so I went with it. Consider:

  Package: foo%type[nox]
  Type: nox (-nox "")      # one variant has "-nox", the other ""
  Depends: (%type[nox] "") x11
  CompileScript: <<
    if [ %type[nox] == "-nox" ]; then
      ./configure %c --without-x11
    else
      ./configure %c --with-x11
    fi
    make
  <<

dan

-- 
Daniel Macks
dmacks@...
http://www.netspace.org/~dmacks

Daniel Macks wrote:
<snip>
> 
>   Package: foo%type[nox]
>   Type: nox (-nox "")      # one variant has "-nox", the other ""
>   Depends: (%type[nox] "") x11
>   CompileScript: <<
>     if [ %type[nox] == "-nox" ]; then
>       ./configure %c --without-x11
>     else
>       ./configure %c --with-x11
>     fi
>     make
>   <<
> 
I think that looks nice. I do not know why, but I like the "FLAVOR" 
thingie that comes with BSD ports systems.
Just because I can combine FLAVORS arbitraraly.

so if there are FLAVOR x11 ssl huge

I can build

only x11 , x11 + ssl, ssl + huge, only huge and so on, you get it.
Is that something we could achieve as well ?

On a second note I think  (%type[nox] "") is not such a hot syntax, 
maybe there is a way to express the "" part in an more clear fashion ?

-d

> dan
>

On Thu, Feb 12, 2004 at 08:20:28PM +1300, Nigel Stanger wrote:
> Darian Lanx at dmalloc@... spake thus:
> 
> > On a second note I think  (%type[nox] "") is not such a hot syntax,
> 
> It just confuses me. Is that supposed to be an "equals" constraint? If so,
> why not just say so and make it clear rather than leaving the package
> creator guessing?
>
> There are plenty of widey-used, well-known and well-understood expression
> syntaxes around, I don't see why we should invent a new and obscure one :)


#fink had similar thoughts this afternoon (I think you had already
left, dmalloc:( including that comparisons would be nice and that we
already have comparison syntax in the parens after a package name for
versioned dependencies, so why not before also. Which brings us to:

  Depends: (thing1 op thing2) package
  Depends: (thing) package

The two things are compared according an operator (one of: << >> == !=
<= >=). As an alternative we could also have the latter case which
checks for thing being non-null (or some "true" enum).

dan

-- 
Daniel Macks
dmacks@...
http://www.netspace.org/~dmacks

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Nigel Stanger wrote:

<snip>
| I ended up building my own XML front-end for building fink packages. I
| now create a single XML file that has all variants of the package in it,
| then run it through an XSLT processor with the appropriate variant
selected
| to generate a .info file for that specific variant. It won't be that
hard to
| modify it to fit whatever approach you guys eventually decide on for
| variants.
|
| If anyone's interested,
Yes, yes, yes.
| I can look at polishing this stuff up and making a
| fink package out of it.
Please do so. I would be delighted to have such an additional package
that we could offer to newbie packagers. This would also make it easier
for third parties to generate info files for their projects that can be
readily included after they have verified compilation on Mac OS X

I've been thinking about doing it for a while, but
| have been too busy with other things. Note that I probably won't be
able to
| get to it for a little while at the moment. It takes a fair bit of
work just
| keeping it up to date with all the ongoing changes to the .info file
| internals :)
|
Oh and since you seem very handy with the tools (xml + xslt) care to
join the web-team and look at the web-site (grin) :)

- -d


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAKzIZPMoaMn4kKR4RAwRcAKCAgUu0yHevpe3C2qZhJZABlD2CggCfSrpW
IvpPvHtLHN8LvKpadqC2hV4=
=R3s+
-----END PGP SIGNATURE-----

On Thu, Feb 12, 2004 at 08:40:37PM +1300, Nigel Stanger wrote:
> On 12/2/2004 10:22 AM, Daniel Macks at dmacks@... spake thus:
> 
> > For the Depends logic, I think the bleh-or-blah would not be a very
> > common occurance. More often (at least in the situations I can think
> > of) is "bleh only if [something]" *or* "blah only if not [something]".
> > Having to conjure up a "nox" package just to make the logic work
> > bothers me. But if people think if/then/else is the way to go...
> 

> If you don't put it in, you can guarantee someone will promptly come
> up with a package that requires it :)
>
>     Depends: perl = 5.8.1 ? bleh.pm : blah.pm
>     Depends: X = yes ? x11 :
> or:
>     Depends: X = yes ? x11 : %null
> 
> where "%null" (or "%none" or whatever) is a special token to indicate "no
> package". I put a % on the front to avoid the problem of a package that's
> actually named "null".

The much more common case that I can think of doesn't use else, and
those two solutions still look kinda convoluted. while if/then/else
could be useful in some cases, I'd rather not clutter up the syntax
for these less common situations. If we allow comparison operators
other than just =, we don't even need else at all:

  Depends: (perl == 5.8.1) bleh.pm, (perl != 5.8.1) blah.pm

dan

-- 
Daniel Macks
dmacks@...
http://www.netspace.org/~dmacks