quilt-dev
[Top][All Lists]
Advanced

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

Re: [Quilt-dev] Protection against double inclusion of scripts/patchfns


From: Andreas Grünbacher
Subject: Re: [Quilt-dev] Protection against double inclusion of scripts/patchfns
Date: Thu, 2 Jul 2020 19:13:31 +0200

Hi Jean,

Am Do., 2. Juli 2020 um 14:44 Uhr schrieb Jean Delvare <jdelvare@suse.de>:
> Hi Andreas,
>
> All quilt commands start by sourcing scripts/patchfns, but before doing
> so, they check whether this file has already been sourced. Looking at
> the code, I can't see any case where the file would have been sourced
> already (it is being sourced exactly once in each command-specific
> file). Can you remember why you added that check?

I'm not quite sure. It doesn't seem to be because of the --trace
option, and neither because of recursive calls (quilt_command).

> The only thing that came to my mind was that maybe you wanted to make
> it possible to pre-source the file so that individual commands do not
> need to do it again. That would make sense from a performance
> perspective, however I don't think this can be done at the moment,
> because a number of checks in scripts/patchfns are context-dependent
> (sourcing of $QUILTRC, addition of default arguments for the command,
> discovery of the source tree's root, setting of $QUILT_PATCHES,
> $QUILT_SERIES and $SERIES, version check and now series check). So it
> would only work if we would split non context-dependent code to a
> separate file and pre-source only that file.
>
> Whether we ever want to do that or not, I'm not sure, as it would
> seriously clutter the shell's environment, especially considering the
> lack of namespace marker for all functions in this file.
>
> So I am considering removing the check for double inclusion. Do you
> have any objection to me doing that?
>
> If the check is really needed then I'd rather move it to
> scripts/patchfns itself so that it isn't duplicated in every
> command-specific file, pretty much as is traditionally done for C
> header files.

Just try it out, I guess.

Thanks,
Andreas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]