Re: Can we combine efforts for C++ project skeleton creation?

Christof Petig wrote:
> 
> Dear fellow hackers,
> 
> As the maintainer of glademm I had been developing a
> program which sets up a skeleton project (ready to
> compile) from a glade file.
> 
> [Should we restrict the discussion to only one list
> e.g. to the gnomemm or glademm list?]

Please let us know if so!
 
> Recent discussion with Murray (maintainer of
> [lib]g*mm ;-) ) lead to the thought that this
> should get delegated to a shared program.

What does a shared program mean?

> So if there's enough interest and we manage
> to define the program's behaviour, I step forward
> as a possible co-maintainer [no I would not do
> it alone, had enough of this stuff with glademm].
> 
> Specification:
> - C++, python and bash are all fine with me (and
> I would accept any other language as a non-maintainer)

I would work/collaborate for Perl, in the extents of my knowledge and
time.

> - configure.in, Makefile.am, po, src etc. should get
> generated by default.
> - since the myriad of imaginable options (check for
> libglademm, which gnome version to test for, intltool,
> gettext, libtool, ...) make a command line specification
> tedious I propose for an XML file for specifying
> additional options (which kills bash IIRC).
> 
> Any ideas on how it should work?

What follows isn't a suggestion but a question (_not_ glade specif one.
I'm even dubious if it should live in this thread, so fill free to
detach it):

How is the simplest way to add, say, glib dependence into a C program?
What should I write in configure.in and Makefile.am? Is there a portable
way to assure that build process will find m4 and other obscure
dependences? Is it the same for any /g.+/ package? Is there common code?
Is it the same for C++?

I would love if you could just say me "see that link...", but don't
believe it was written yet. Yes, of course I would volunteer for that
tutorial, but after learn it better. All of my programs suffer a lot
before configure is ready.

Silvio

>     Christof
>
> PS: The recent glademm behaviour is as follows:
> - never overwrite any file (instead create e.g.
> configure.in_new)
> - gettext, gnome etc. are tested according to
> glade's preferences
> - generate an example main() [creating all toplevel
> widgets, waiting on the first, cleanup, exit]
> - generate a user class (.cc + .hh) and a UI class
> (_glade.cc + _glade.hh) for each toplevel widget. This
> might include setting up and calling libglademm.
> - simply try it ;-)