home contents changes options help

While this is just a guess, I would be willing to bet that the vast majority of users under Windows will simply want the binary and under windows that means they simply want an executable that they can run and will install everything. Even copying a file around manually (like a new plug-in into a specific directory) usually seems to be to much to ask for windows users. (I know I"m show a little bias here sorry). Doing a quick look back over the film-gimp and cindepaint mailing list archives I was unable to find a single request for any type of build system outside of Visual C++.

The reason I even mention this is that when looking at autotools and pmk, any possible win32 issues were simply ignored. Making the assumption that using VC++ project files would be the best, and currently only needed, means of building under win32.

> > Tom, thanks for the PMK patches last week! I haven"t > looked at them yet. Do > you have findings to report from your research into > PMK? How hard is it? > Will it scale well? Does it seem robust? > Well-supported? Thoughts? >

PMK itself is very simple to both install and to use. It seems to scale well. For example, with img_img it is set up to allow a new plug-in to be added to the source tree by adding a small block of text to the "pmkfile" (I placed a sample block in the pmkfile so it could be copied and just have the values changed) and then copy the "Makefile.pmk" file from any of the other plug-ins and just make changes to a few lines at the top of the file. From a build point of view adding a new plug-in can be quickly done in just a few miniutes.

It seems fairly robust. I didn"t have any problems with it, there is a low trafic mailing list available for help from the developers, and they seem quick to respond to posts based on the dates in the archives. I have not yet needed to post to that list, so I do not know first hand about available support from the developers.

I personally think that PMK is a winner over autotools. It is MUCH simpler. With autotools there are is just to much stuff to keep track of: autoconf automake autoheader autoscan libtool make

all of which interact with each other in not particularly obvious ways. Some things with automake are in the configure input file for example.

With pmk you also have interaction, but at a much more basic and simplistic level. Also the interaction is only in a single direction.

there is pmk itself, which is essentially controled by a single file within the build tree called "pmkfile" The syntax for the file is simple and well documented. After going through the pmkfile, it then creates makefiles from a series of template makefiles, similar to Makefile.am files in autotools.

All you need to know is pmk, which is small, easy to learn, and intuitive. And make, which pretty much everyone knows anyway since it"s been around forever. Optionally, knowing shell scripting is usefull, but only needed if you use it from the Makefiles, and pretty much everyone knows that too.

pmk itself is only used to set variables for use in standard makefiles. It is usefull for checking for libraries, header files, specific library functions, and binary executables. It is up to the Makefiles to then use this information.

The pmk website lists pmk as working under linux and Free/Open/NetBSD. I have only used it under linux however as that is all I have available to me.

The implementations for gel and img_img are relatively simple since they are fairly small projects. I"ve started an attempt to switch the current CVS version of cinepaint over to pmk to seem how it goes on a larger more complex build. So far it goes well, but I have only build libcinepaint at this point.

laters, Tom