Hi, > I have prepared a patch to generate an AmigaOS4 shared library from > the pixman sources. My first question is whether you would, in > principle, include something like this in the main git? And if, how > can I best distribute the patch? The patch is quite large as it is > about 300k is size. Apart from a patch that I submitted previously and > a small style correction (which I will remove subsequently) it doesn't > change anything to existing files. It, however, adds some new files to > a new amiga directory, which hosts stubs and other related files > necessary to build a real AmigaOS shared library, and some makefile in > a similar fashion as the Win32 port does. A preliminary patch is > accessible using the > http://www.sebastianbauer.info/ex/pixman-amiga.diff URI.
I have pushed the const fix in pixman-matrix.c to master - thanks for the patch. The style fix in pixman-region.c also looks good. If you send it as a stand-alone patch, I'll push that as well. Regarding the build system support for AmigaOS, I'm inclined to say that we are not interested, simply because it's a very big chunk of code that will benefit only a very small number of users, and that most people working on pixman have no chance of maintaining. Since the patch is relatively independent and only touches one new directory, I think it shouldn't be a huge problem for you to maintain it as a separate branch in a git repository somewhere - ie., rebasing to newer versions of pixman wouldn't generate a lot of conflicts. This doesn't mean that we wouldn't be interested in changes to the actual pixman code that would benefit AmigaOS, such as new Altivec fast paths, or if there are small extensions required to the various OS or compiler specific parts of pixman. > Another question is about fast path caches in pixman-utils.c. I didn't > study what the fast path cache (nor what a fast path) is all about but > as on AmigaOS TLS cannot be achieved that easily and all code and data > is shared for all clients, I would like to extend that code portion by > a compile-time optional data access arbitration method. Would you, in > principle accept this change as well, assuming a suitable > implementation is provided? I'm not sure what you mean by "compile-time optional data access arbitration method", but if you mean using mutexes instead of TLS, then I wouldn't necessarily be opposed to a patch that did this in a suitable way. Thanks, Soren _______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman