On 1/4/20 6:25 am, Eli Schwartz wrote:
> On 3/31/20 4:12 PM, Anatol Pomozov wrote:
>> C18 is the latest stable specification of the language that is
>> supported by modern toolchains.
>> It sounds reasonable to me if pacman keeps up with the technology
>> stack and uses its advancements.
>
> What advancements are used as a direct result of passing -std=c11? What
> generated object code does this patch *on its own*, change?
>
>> Are you saying that C18 requirement introduces limits due to
>> requirement of this 2 years old toolchains? Just curious what
>> platforms where pacman is used lacks these toolchains?
>
> The limit it introduces is "over-specifying requirements".
>
>> It is not really required to use all the spec features right away. But
>> having an option to use it in the future is gonna be useful.
>>
>> As of particular use case - if in the future we decide to speed-up the
>> installation with more thread-level parallelism (e.g. checking
>> signatures/unpacking/... on multiple CPUs) then better C11
>> mutlithreadding support is very useful.
>
> If we need it in the future, we can add it in the future. Am I missing
> something?
>
> If I add a new pacman feature that relies on libfoo.so, I add a
> dependency on libfoo.so -- but does that mean I submit a patch the year
> before, to "pass -lfoo when building pacman, to make the libfoo library
> an option since it will be useful in the future"? No, I submit a patch
> that introduces the use of libfoo functions, and in the same patch, I
> add -lfoo to the build flags.
>
> So, it seems reasonable to wait until we want to add c11 features to
> pacman, and then submit a patch with the new features, and bump the
> minimum-required-language-version argument at the same time.
>
Also...
configure.ac:186: error: possibly undefined macro: AC_PROG_CC_C18
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
