mingw-cross-env-list
[Top][All Lists]
Advanced

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

Re: [Mingw-cross-env-list] [patch] new package: freeimage


From: Volker Grabsch
Subject: Re: [Mingw-cross-env-list] [patch] new package: freeimage
Date: Wed, 17 Feb 2010 03:02:52 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

Mark Brand <address@hidden> schrieb:
> 
> > 1)  The build failed immediately, because the patch didn't work.
> >     The patch is for Makefile.gnu which is a DOS text file, and
> >     somehow the patch didn't contain any CRs, so it didn't match
> >     any line.
[...]
> I don't really like the idea of having to worry about invisible
> end-of-line conventions in patch files.

Things aren't that bad. The "hg diff" and "patch" tools are
doing their job fine, regardless the source file's line endings.

> Since we only patch text files, maybe it would be
> better to keep the patches  as unix text files that can be applied to
> unix text files. Before applying the patch, we would run dos2unix on the
> file target if necessary.  What do you think about that?

That would mean we'd have to convert automatically all text
files of the source tarball after unpacking. Or we'd have to
figure out which files the patch is going to change, and convert
them before applying the patch.

All in all, that's too much trouble for such a small issue
that can't be overlooked, i.e. the build fails quickly, and
the failure points directly to the patching.

The only problem here are patches via email, but that's easy
to solve: Just compress your patch (or hg export) with gzip
before sending it. I won't mind the extra "hassle" of unzipping
that file before I import it. ;-)

> > 3)  The FreeImage package contains the sources of many image libraries
> >     which are already part of mingw-cross-env. Is it possible to make
> >     FreeImage use those instead of baking its own ones?
> 
> Perhaps these are modified sources or could become modified sources
> without warning. I really don't know. This raises a philosophical
> question. Would it still be FreeImage if we did that?
> 
> Are there strong arguments for doing this?

No, there are just weak arguments. I was mainly thinking of
other packages such as wxWidgets or Qt, which also contain
some other libraries, but we configure them to use the external
libs instead.

However, FreeImage might be an exception, I don't know. Maybe
their integration is very tight compared to the integration
of e.g. libpng in Qt. That's why I was asking.

BTW, that's the fourth library of that kind. We already have
SDL_image, GD and DevIL, which do roughly the same as FreeImage.
It seems that image libraries are hip nowadays. ;-)


Greets,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR




reply via email to

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