Re: [PATCH 04/22] mkfs: change conflicts array into a table capable of cross-option addressing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 16, 2017 at 6:02 PM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote:
> On 3/15/17 8:59 AM, Jan Tulak wrote:
>> Change subopt_param.conflicts from array of integers into array of structures.
>> This prepares the ground for more universal conflict detection in future
>> patches.
>>
>> Signed-off-by: Jan Tulak <jtulak@xxxxxxxxxx>
>> ---
>>  mkfs/xfs_mkfs.c | 243 ++++++++++++++++++++++++++++++--------------------------
>>  1 file changed, 129 insertions(+), 114 deletions(-)
>>
>> diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c
>> index 5e15fee2..c9861409 100644
>> --- a/mkfs/xfs_mkfs.c
>> +++ b/mkfs/xfs_mkfs.c
>> @@ -93,8 +93,16 @@ unsigned int               sectorsize;
>>   *
>>   *   conflicts MANDATORY
>>   *     If your subopt is in a conflict with some other option, specify it.
>> - *     Accepts the .index values of the conflicting subopts and the last
>> - *     member of this list has to be LAST_CONFLICT.
>> + *     Accepts the .index values of the conflicting subopt as .opt (e.g. OPT_D)
>> + *     and .subopt (e.g. D_FILE). If .test_values is true, then the conflict
>> + *     is raised only when the "remote" suboption .value is equal to
>> + *     .invalid_value field and the "current" suboption has .value equal to
>> + *     .at_value.
>> + *     If .test_values is false, a conflict is raised when the suboption appears
>> + *     on the CLI, no matter its value. The field .message contains an optional
>> + *     explanatory string for the user. This string can't be translated here,
>> + *     so it has to be enveloped with _() when printed.
>
> You also still need to mark each string initializer you added in the array
> in patch 08 with N_(" ... ") or gettext won't know about it.
> (I think that's the right way to go about it)
>
> -Eric

See patch 06, the last chunk. It adds printing of the error with
"_(conflict->message)".
So if C gettext is a function evaluated on the run and not a macro
evaluated on the compile time, then it should be ok. (And everywhere I
looked, I saw it mentioned as a function... Although I admit I didn't
tested it.)

Jan




-- 
Jan Tulak
jtulak@xxxxxxxxxx / jan@xxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux