Re: [Mingw-cross-env-list] new tool: patch-tool-mingw

[Mark Brand]

I have checked in a script to make it easy to convert between patch  
files and short-lived git repos. This version is newer than the one I  
already shared with some of you.

http://hg.savannah.gnu.org/hgweb/mingw-cross-env/rev/5d51efc6e43a

There's room for improvement, so feel free to criticize, improve,  
rename, etc.

I see fundamental design flaw in the tool, and in the idea of
having a bunch of shell scripts in a "tools/" folder.

I don't like "tools/" either. I just saw it as a temporary solution to get it "out there". I wanted to get it out there so users would have an example of workflow using git (or hg) to manage patches instead of using "diff -urN" on directories.

1)  We already have a convenient interface that covers lots of
    small tools. This interface is "make [args]". Why inventing
    another interface "sh tools/action [args]"?

Yes, I think it would be good to do this with make. The bash script was just my first crude attempt to get it working. I don't consider it a final product by any means. But for me, it was a lot better than nothing.

2)  Although not everyone likes GNU Make's macros, they at least
    provide _some_ means of abstraction. Doing that in Bash is
    almost impossible. So the choice of language is far from
    optimal.

3)  The main Makefile provides lots of helpers for the package
    files (src/*.mk, src/*.patch, ...). Not using them means
    having to parse those files "by hand", and this is what
    quite a big part of your shell script does.

I completely agree. Again, that parsing was just a quick hack to get it working.

I see 2 approaches to improving the current situation. The first invokes make from the bash script to parse the pkg strings. The second involves implementing the "init", 'import", "export" functions in the make file, so the makefile invokes smalls bits of bash instead of the other way around. The second approach seems clearly the right one, consistent with the design of mingw-cross-env.

4)  The script uses Git for no good reason. That is, it doesn't
    use any of the advanced Git features. Everyone who uses the
    development version of Mingw-cross-env already has Mercurial.
    Why requiring them to install yet another tool for the same
    job?

Here are my reasons for using git:

The user can use the "advanced Git features", particularly "git rebase -i" before exporting work back to the patch file.

Supports "git format-patch" format which is probably something like a standard.

But there's no reason that hg couldn't be used here. We might have to sacrifice the "git format-patch" format.  It would be nice to have a format that works with git and hg so the choice would be up to the user.

5)  Separate shell scripts may automate some tasks, but still
    require a quite cumbersome workflow. Why not thinking about
    the workflow _first_? For instance, why not creating a mode /
    command that does a normal build, and if one packages fails,
    creates an ad-hoc repository automatically, filled with the
    already exported patches? When calling "make" or "make PKG"
    after that, the patches could be recreated from the repository
    automatically before the build starts.

That sounds reasonable, but that would be an application of the basic "init", "import", "export" functions prototyped in my bash script, right?

Mark