Re: [Mingw-cross-env-list] How to write .mk for libraries that have no source releases?

[Mark Brand]

> > > I'd like to write a .mk for a library which is only git available (
> > > http://www.videolan.org/developers/libbluray.html ).
> > > How can I write $(PKG)_URL variable and $(PKG)_UPDATE section?
> > That's a good question that hasn't really come up yet. Since there
> > really is no package tarball, there should some kind of null $(PKG)_URL,
> > maybe pointing to /dev/null.
> I strongly disagree with this, see below for explainations.

I disagree with my idea too, at least in its pure form.  As you pointed 
out later, the entire commit history of a package makes the patch file 
much too big.

> We'll have to find a proper solution to this.
>
> One helpful detail is that the Git web interface allows for
> downloading a certain version as tarball. See below for my
> thoughts about using hashes as version numbers.

I agree it makes sense to use generated tarballs, assuming a good 
solution to the hash problem.

One thing you might want to consider is whether each new commit in the 
git repo should necessarily be seen as an "upgrade". Depending on how 
you look at this, it might make sense to use a well-tested generated 
tarball from the git service as a sort of baseline "release". An option 
would be to put later less well-tested commits in a patch file, so they 
could easily be undone in case of trouble. It partly depends on whether 
the mingw-cross-env packager wants to play the role of release manager 
for the package in question.

Mark