1 |
Dnia 2015-10-14, o godz. 20:52:30 |
2 |
Ulrich Mueller <ulm@g.o> napisał(a): |
3 |
|
4 |
> >>>>> On Wed, 14 Oct 2015, Michał Górny wrote: |
5 |
> |
6 |
> >> IF first parameter begins with a hyphen AND any parameter is equal to -- |
7 |
> |
8 |
> > Hmm, that's not exactly correct. All parameters preceding -- would have |
9 |
> > to begin with a hyphen. So maybe... |
10 |
> |
11 |
> > IF any parameter is equal to -- AND all parameters preceding it |
12 |
> > being with a hyphen |
13 |
> |
14 |
> Well, there could be option arguments, too. And we don't know which |
15 |
> patch options can have arguments, unless we copy the option parsing |
16 |
> from patch(1) which is not feasible. |
17 |
> |
18 |
> My wording was like this on purpose, and the idea is that if the |
19 |
> ebuild author has specified an explicit -- separator, then we assume |
20 |
> the he knows what he is doing. So we pass the whole part before the -- |
21 |
> as options (plus possibly option arguments) to patch. |
22 |
|
23 |
Oh crap, I totally forgot about option arguments. Then yes, probably |
24 |
using -- to allow them makes sense. |
25 |
|
26 |
> >> collect all parameters before the first -- in the options array |
27 |
> >> collect all parameters after the first -- in the files array |
28 |
> >> ELSIF any parameter beginning with a hyphen follows one without a hyphen |
29 |
> >> return an error |
30 |
> |
31 |
> > Not sure if we should really specify error handling here. The idea is |
32 |
> > that this is incorrect syntax, so it is unconditional fatal error. |
33 |
> |
34 |
> Sure, s/return an error/abort the build process/ |
35 |
|
36 |
Ok. |
37 |
|
38 |
> >> ELSE |
39 |
> >> collect all parameters starting with a hyphen in the options array |
40 |
> >> collect all parameters without a hyphen in the files array |
41 |
> >> ENDIF |
42 |
> |
43 |
> >> patch -p1 -f -g0 --no-backup-if-mismatch |
44 |
> |
45 |
> > Ok. |
46 |
> |
47 |
> Good. :) |
48 |
> |
49 |
> >> We should say something about error handling. For example, does the |
50 |
> >> function return when it encounters the first error of a called |
51 |
> >> patch(1)? |
52 |
> |
53 |
> > Where should I say it? Put in the algorithm? |
54 |
> |
55 |
> Not sure, error exits tend to be clumsy. Does the algorithmic package |
56 |
> include a GOTO statement? :) To be serious, maybe it's best to leave |
57 |
> it out of the algorithm for better clarity, and put it into the |
58 |
> description instead. |
59 |
|
60 |
No, it doesn't have a GOTO. But I think I can just put a STATE telling |
61 |
it to exit. |
62 |
|
63 |
> What about nonfatal, BTW? We should be consistent with other commands |
64 |
> there. |
65 |
|
66 |
Yes, that's the design. Dies without it, exits on first error with it. |
67 |
|
68 |
-- |
69 |
Best regards, |
70 |
Michał Górny |
71 |
<http://dev.gentoo.org/~mgorny/> |