Hi Danek, I have a brief discussion with Simon after his last reply. I think I managed to 'convince' him that gmmproc is really a project private [1] interface. That is it is provided by glibmm to allow itself and other gtkmm modules to generate C++ code from specification language such as defs and so on. Its use outside gtkmm itself not not very generic as C++ developers are likely to write their apps from scratch or other tools and unlikely to use gmmproc.
I am in the process of updating the interface table and also consolidate the various discussion points. Would like to do a quick review before I send out to this list again. Mostly by this time tomorrow :) Thanks -Ghee [1] Whatever the equivalent of the new taxonomy :) need to check. Danek Duvall wrote: > On Sun, Feb 10, 2008 at 12:48:50PM +0800, simon.zheng at sun.com wrote: > > >> To generate .h and .cc files from .hg and ccg, gmmproc is executed like >> this. >> >> $./gmmproc -I ../../tools/m4 --defs ./src >> >> Here, -I and --defs specifies m4 files and .defs files directory. That >> it, gmmproc needs to cooperate with two kinds of files, .m4 and .defs. >> In fact, gtkmm svn repository has included these files beforehand. >> Therefore, no extra work for them needs to be done when building. >> >> The complete steps is below: >> - STEP 0: Write .m4, .ccg, .hg files and prepare .defs files, put them >> into svn repository. This is done before real building. >> - STEP 1: Preprocess of building. Use gmmproc to get .c and .h source >> files. >> - STEP 2: Compiling of building. Create gtkmm library from source files. >> > > Is this for any project based on gtkmm, or is this just when building > gtkmm? The way you write the gmmproc commandline and then this step 2 > sounds like the latter. I mostly don't care how you build this project; I > care about how developers basing their own projects on this one will use > the interfaces you provide. > > >>> Is generate_extra_defs something you'd put in a makefile to run over >>> the .hg and .ccg files to generate a .defs file? >>> >> No, generate_extra_defs isn't put into any makefile. Usually >> generate_extra_defs is run manually by the developer to generate new >> .defs file, and then put these pre-generated .defs file into source >> repository. >> > > Sort of like checking .o files into the repository? Why don't developers > simply keep the source checked in, and all derived files built via the > build system? > > >> For example, when gtk+ C library is upgraded and a new widget class is >> added, gtk_signals.defs needs to be updated accordingly. Firstly, the >> developer modifies generate_defs_gtk.cc, then build generate_extra_defs >> binary. After that, he run generate_extra_defs manually to generate the >> new gtk_signals.defs. Finally he put the gtk_signals.def into svn >> repository. >> >> In one word, generate_extra_defs is just used to generate .defs before >> real building. So we don't develiver libglibmm_generate_extra_defs-2.4 >> library. It's private. >> > > I think I'm understanding the architecture here less and less. Are you > talking about building gtkmm, or some random other project that uses gtkmm? > > >> - Keep gmmproc public. Since it's only used by building rather than by >> users directly, I hope move to /usr/lib/gmmproc, just like part of >> "/usr/libexec" on Solaris. Do you think it's reasonable? >> > > /usr/bin hold plenty of executables that are only useful to developers, so > that's where I'd expect it to be. Do typical linux systems put it in > /usr/libexec? If so, do makefiles and configure scripts tend to try to > find it there? > > Danek >
