Edit detail for PMK vs libtool comparision revision 1 of 1

1
Editor: 10.1.0.1
Time: 2005/04/12 11:33:21 GMT+0
Note:

changed:
-
 > Visual Studio dominates Windows. The autotools
 > enthusiasts your imagine 
 > preferring it on the Windows platform are just that
 > -- imaginary.
 > 
 
 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

> Visual Studio dominates Windows. The autotools > enthusiasts your imagine > preferring it on the Windows platform are just that > -- imaginary. >

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