Browse files

*** empty log message ***

  • Loading branch information...
1 parent fac3b96 commit e8d9366cac0e83a1728c1517f27f50af84dcc609 masse committed Jan 4, 2007
Showing with 211 additions and 0 deletions.
  1. +211 −0 lib/gtkNode/ROMAIN.txt
@@ -0,0 +1,211 @@
+Maybe you have noticed my blog entry on gtkNode [1], and you
+should have noticed the patch that I have already submitted [2].
+Here I send you a profound modification of gtkNode, concerning
+the configuration and build process:
+- it makes use of GNU's Autoconf and Automake, and especially
+makes use of the Autoconf macros for Erlang that will be soon
+added to Autoconf [3]: simply execute the classical
+"configure; make; make install";
+- the configure script is well documented (thanks to my
+Erlang-specific macros!): ./configure --help;
+- my files support out-of-tree building (which is a
+recommended way of building Automake-based applications...),
+i.e. one can do for instance:
+> > mkdir -p /tmp/gtknode-src
+> > cd /tmp/gtknode-src
+> > tar xvzf gtknode-0.1.tar.gz
+> > mkdir -p /tmp/gtknode-build
+> > ../gtknode-src/gtknode-0.1/configure
+> > make
+I.e., all generated files will be generated in the build tree,
+not in the original tree. It makes it easier to clean up.
+- my files support installation (make install) and
+archive building (make dist); notably, the attached
+gtknode-0.1.tar.gz was produced by executing
+"configure ; make dist";
+- they also support the DESTDIR variable as a prefix for testing
+installation. E.g. one can execute:
+> > configure
+> > make
+> > make install DESTDIR=/tmp/testinstall
+and all files are installed under /tmp/testinstall...
+- I have moved files and directories around to better respect
+OTP's design principles [4], and Jungerl's directives [5]: all C
+code goes into 'c_src' and only Erlang code stays in 'src', etc.
+- I have renamed 'gtkNode' into 'gtknode' in Erlang code, to make
+it more similar to the other Erlang/OTP libraries (e.g.,
+'Jinterface' is named 'jinterface' in the code);
+- I have much simplified the code generator; notably, 1) I have
+simplified generator.erl to not determine file names itself, but
+to let it to the configuration/build environment, and 2)
+generated file names do no more contain the GTK version number
+(although I can easily revert that precise change if you
+- examples have been moved into the 'doc' directory (although I
+am not sure about this, and I still don't know to which
+directory to install them on a 'make install');
+- I have slightly modified gtknode.erl to make use of
+code:priv_dir/1 instead of manual directory building;
+- I have maybe forgotten something in this list... and I have not
+yet updated the ChangeLog.
+I have also attached the erlang.m4 file that contains the
+Autoconf macros that you would need to build that version if you
+modify anything. To install those macros, see [3].
+My motivation for that refactoring was to be able to easily build
+a (non-official for now) Debian package of gtkNode. Using GNU's
+Autotools it is now trivial. And I hope that it would make it
+easy to build gtkNode on Windows.
+I am waiting for your comments on that work, and your
+aknowldegment before I create and publish a Debian package.
+I know this is a big refactoring, but I am willing to help you
+integrate most of my modification if there is any problem.
+There are still interesting perspectives regarding packaging,
+such as making gtkNode a real Erlang/OTP application (i.e. write
+a .rel file, etc.).
+Best regards,
+> > p.s. what are you using this for? gtkNode, kerberos-slaves...
+> > or is it secret?
+I have published nothing about that yet, but I can tell you a
+bit... I am developing a H.323 VoIP system in Erlang and based
+on real-time Ethernet networks, as a demonstration of a method I
+am defining for the design of open distributed management
+systems. (H.323 gatekeepers and gateways form in fact a big
+distributed management system...)
+I use of Kerberos/remctl to start slaves for monitoring. I am
+using IDX Tsunami's ts_os_mon module, and traditionally they use
+ssh. But ssh is not practical when monitoring more than a couple
+of systems (have to distribute public keys, etc.)
+As for gtkNode, I shall be able to make demos in the future, and
+a management console in GTK+ has more appeal than a TK-one.
+> > alas, i'm not very proficient open-source guy... your blog
+> > was very nice though.
+I mentioned my blog only because this article was the occasion I
+chose to register it on ;-)
+> > but you need to be root to install this macro package? so
+> > no normal person could do it? (including me, unless i crack
+> > root on my work machine).
+For now, yes. But I have submitted the macros for inclusion into
+Autoconf, and they accepted. We are making the copyright
+transfer paperwork, so it could still take one week or two.
+You also have the possibility to simply put the macros directly
+into the aclocal.m4 by hand:
+> > cat erlang.m4 >> aclocal.m4
+That is all! (and I should have done that myself before sending
+the archive to you...)
+aclocal.m4 is simply a local copy of all the M4 macros used by
+the file, that can be distributed with the project.
+aclocal.m4 is created by aclocal by (badly) recursively
+But it does not include macros that are part of Autoconf itself
+since Autoconf has its own system-wide macro cache.
+Anyway, in the meanwhile I have made a Debian package to make
+installation of erlang.m4 trivial. (I am working on setting up a
+personal archive for APT, and I am waiting for the copyright
+transfer to be OK before publishing that package).
+>> > > environment, and 2) generated file names do no more contain
+>> > > the GTK version number (although I can easily revert that
+>> > > precise change if you prefer);
+> >
+> > well, there is a reason for this (although a pretty bad
+> > one); at work i build the linux and the solaris versions on
+> > the same file system. of course, the have different GTK
+> > versions... i guess the out-of-tree build is The Right Thing
+> > (tm).
+Ok, so I guess that naming the binary executable "gtkNode-linux",
+etc. was for the same reason.
+From a Debian packaging point of view, having binaries with
+arch-dependent names was a bad thing also.
+>> > > - examples have been moved into the 'doc' directory
+>> > > (although I am not sure about this, and I still don't know
+>> > > to which directory to install them on a 'make install');
+> >
+> > i think priv/examples is canonical.
+Ok, I will change this.
+And I will also make it configurable through ./configure options,
+because on Debian they should go
+into /usr/share/doc/gtknode/examples.
+> > btw, have you seen erlmerge?
+> > seens like a
+> > good idea.
+I don't like the idea of mixing configuration and installation
+concerns. For configuration nothing beats Autoconf, and for
+installation nothing beats native packaging systems such as
+Debian's or RPM, etc.
+Just compare erlmerge with Debian packaging: erlmerge does not
+have meta-packages nor tasks, does not have "Suggests" or
+"Recommends" dependencies (only "Depends" ones), does not have
+disjunctions of dependencies (e.g. "mnesia | odbc"),
+dependencies are only to specific versions of apps (e.g. it is
+not possible to depend on "stdlib (>= 1.12.7)"), etc.
+And having programs making their own package management in
+parallel to the native system's system ends up with a mess for
+managing upgrades, with multiple versions of apps installed in
+parallel by every application or user with its own package
+system... Wait... but that's Windows?! ;-)
+Plugin-based apps such as Eclipse, and Jakarta Maven (the
+equivalent of erlmerge for Java) or Pear (idem for PHP) have the
+same problem...
+Also I don't see how to use erlmerge to manage the configuration
+and building of multi-language projects such as gtkNode, which
+need to build and install arch-specific binaries?!
+The ideal solution would be to enhance Automake to handle Erlang
+files: .erl, .rel, .app, etc. But Automake seems much more
+difficult to modify than Autoconf (which is all M4-based).
+Just for one reason: Automake is essentially one big Perl script.

0 comments on commit e8d9366

Please sign in to comment.