Skip to Content.
Sympa Menu

sm-commit - [SM-Commit] RFC: Declarative DSL for applying patches [was: Re: GIT changes to master grimoire by Ismael Luceno (ebb3d4ea0344f74a552a75a2b3f4df78275aa44c)]

sm-commit AT lists.ibiblio.org

Subject: Source Mage code commit list

List archive

Chronological Thread  
  • From: Ismael Luceno <ismael.luceno AT gmail.com>
  • To: Thomas Orgis <thomas-forum AT orgis.org>
  • Cc: sm-commit AT lists.ibiblio.org, sm-discuss AT lists.ibiblio.org
  • Subject: [SM-Commit] RFC: Declarative DSL for applying patches [was: Re: GIT changes to master grimoire by Ismael Luceno (ebb3d4ea0344f74a552a75a2b3f4df78275aa44c)]
  • Date: Fri, 26 Aug 2016 17:52:10 -0300

On 24/Aug/2016 21:22, Ismael Luceno wrote:
> On 15/Aug/2016 23:43, Thomas Orgis wrote:
> > Am Mon, 15 Aug 2016 15:30:31 -0300
> > schrieb Ismael Luceno <ismael.luceno AT gmail.com>:
> > > Headers we would want:
> > > * X-Patch-Strip (default = 1)
> > > * X-Patch-Label (a shorthand, mandatory for optional patches)
> > > * X-Patch-Deps (list of shorthands)
> > > * X-Patch-Conflict (list of shorthands)
> >
> > I'd rather have such in a declarative-like syntax in the PRE_BUILD … or
> > a PATCHES file, very much like DEPENDS. Separate data (patches) and
> > metadata (dependency information). That way, one also could group
> > patches together for logical features etc. Not sure how the indivudual
> > labels would work there.
>
> OK, if it's not in the patches themselves, I would prefer a PATCHES
> file, as it would make more explicit the info is processed in CONFIGURE
> and PRE_BUILD.
>
> After much thinking, perhaps there are a few scenarios where this is
> more flexible.
>
> The question now is: should this be part of Sorcery itself?

I've made a first attempt at defining a format of PATCHES:
<label> <file> <options...>

Lines starting with a space continue the previos one.

Valid options:
needs - for declaring a depedency
conflicts - for declaring a conflict
strip - the -p parameter to patch

Mandatory patches would have the "-" label.

The "needs" and "conflicts" options would be processed by another
function (select_patches?) to properly generate and order questions
in the CONFIGURE stage.

Order of application is order of appearance in the file.

The following patch implement the part that actually applies the patches:
http://iodev.co.uk/apply_patches_func.diff

The function takes a list of optional patches to apply as arguments.

Dependency resolution would be handled in the selection function.




Archive powered by MHonArc 2.6.24.

Top of Page