Re: [PATCH] Makefile: dedup git-ls-files output to prevent duplicate targets

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

 



On Thu, May 26 2022, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
>
>> I pointed out then that with --sort-by-file added we:
>>
>>  * Don't group the translations by C/SH/Perl anymore
>>  * Change the sort order within files, to be line/sorted instead of
>>    line/order (i.e. first occurring translations first)
>>
>> I suggested then to just use $(sort) on the respective lists.
>>
>> So why not just:
>>
>>  1. Switch to the $(FOUND_C_SOURCES) (good)
>>  2. Filter that by C/Perl/SH as before (just a simple $(filter)
>>  3. $(sort) that (which as noted, also de-dupes it)
>>
>> Then we don't have any of the behavior change of --sort-by-file, and we
>> don't have to carefully curate the ls-files/find commands to not include
>> duplicates (although as seen here that seems to have been a useful
>> canary in the "find" case).
>
> Does "--sort-by-file" really mean that?
>
> The option is documented to sort output by file location, but does
> it mean without the option (i.e. default), there is no guarantee in
> the output order?  Or are we sure that the output is sorted by the
> order of input files, and that is guaranteed to hold in the future?
>
> If we are depending on certain ordering of the output produced by
> gettext suite of programs, I would keep the option, regardless of
> what we do to the input to them, if I were running the i18n part of
> this project.
>
> But I am not, so I would not complain if --sort-by-file is dropped
> against my advice ;-)

The gettext docs are pretty light on the subject, but the default "sort
order" is none at all. I.e. it'll just inhale source and spew out
translations in the order you feed them to xgettext.

So in order of input files, and then in order they're seen in the
program.

I don't think that's ever going to change.

The --sort-output and and --sort-by-file then re-sort that.

AFAICT the --sort-by-file could be more accurately named
--sort-by-file-then-line-number-then-by-msgid.

I.e. the semantics seem to be to sort by file, then emit messages in the
order they appear in the file *by line*, but within a line act as though
--sort-output was given. I don't know if that's intentional or not.





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux