[Gambas-user] configure options

[Dominique Michel]

Le Sun, 9 Feb 2014 16:59:37 +0100,
Tobias Boege <taboege at ...626...> a écrit :

> On Sun, 09 Feb 2014, Dominique Michel wrote:
> > Le Sat, 8 Feb 2014 07:53:27 +0100,
> > Fabien Bodard <gambas.fr at ...626...> a ?crit :
> > 
> > > The Development Environment
> > > 
> > > The Gambas IDE is made with Gambas. In order to compile and use
> > > it, you need to compile the following components:
> > > 
> > > gb.db
> > > gb.db.form
> > > gb.debug
> > > gb.desktop
> > > gb.eval
> > > gb.eval.highlight
> > > gb.form
> > > gb.form.dialog
> > > gb.form.mdi
> > > gb.image
> > > gb.image.effect
> > > gb.qt4
> > > gb.qt4.ext
> > > gb.qt4.webkit
> > > gb.settings
> > > 
> > > Then all the infos are here :
> > > http://gambasdoc.org/help/howto/package?v3
> > > 
> > > Regards,
> > > 
> > > --
> > > Fabien Bodard
> > 
> > Thanks for the info. The issue with gentoo is it install all from
> > the sources, and in order to split Gambas in several package, I
> > have to deal with autoconf in the ebuilds for that.
> > 
> > In configure.ac and Makefile.am, I can remove the directories that
> > doesn't correspond to a given package. If I understand right, if I
> > made a base ebuild with
> > 
> > AC_CONFIG_SUBDIRS(main)
> > AC_CONFIG_SUBDIRS(comp)
> > AC_CONFIG_SUBDIRS(app)
> > AC_CONFIG_SUBDIRS(examples)
> > 
> > I will get a build with the runtime, development, scripter and
> > example packages, and some extras which are parts of the IDE. I can
> > use an USE flag for the examples.
> > 
> 
> Hmm. Not really. You will also get things like gb.report, gb.web or
> gb.memcached from comp/ which are rather highlevel components (not
> ultimately needed to run Gambas and not even the IDE). And you will
> get things like gb.data or gb.inotify from main/lib/ which are also
> unneccessary for a runtime or even runtime + IDE package.
> 
> >> Are any of these components mandatory in order to get a working
> >> minimal Gambas installation?
> >>
> 
> Only the gb component is mandatory actually. And it's built together
> with the interpreter in main/gbx/.
> 
> >> Are any of these components dependent of any other of these
> >> components, and if yes, which one(s) and how?
> >>
> 
> As a rule of thumb: C/C++ components usually (?) don't depend upon
> each other. If they do, they belong to the same "package" anyway,
> like gb.qt4.ext obviously depends on gb.qt4. However, Gambas
> components can depend on other ones in less obvious ways. You can
> scan their .project files for Component= lines to get this
> information.
> 
> >> Are any of these components recommended in order to get a good
> >> experience with Gambas?
> 
> The IDE is a good thing but you can go without (I still have my vim
> syntax files for Gambas sources :-)). Apart from that (which is a
> development tool and not a component but pulls the latter ones in),
> it highly depends on what people want to do. Does gentoo have a
> metapackage kind like "gambas3-things- you-may-like" or why do you
> need this information?

For now, it is a gambas ebuild that install everything, and it is
several USE flags (one by configure flag) to choose which component(s)
must be enabled, compiled and installed. That work fine, but take some
time, especially the autoconf stuff.

In gentoo, this is not the package manager that build a software, but
portage. It run what is in the source, for gambas

libtoolize
autorecomf
configure
make
make install

In the case of a system update and as the gambas' ebuild is now, if
db-qt or any other component get broken, the ebuild will recompile every
thing, which take about one hour in my PC, and even more if it is buzzy
with something else.

Working with the sources with portage is not like working with sources
somewhere in $HOME. All that is left after a portage installation is
the installed files and the source archive. That imply portage will
decompress the sources, and run the whole installation process again as
specified into the sources in any case.

Ebuilds are scripts, so I can tell portage to do whatever I want on
the sources into them. In order to split the actual ebuild into
several ones, I need to not only tell configure what must be compiled
and installed, but to also tell libtoolize and autoreconf to only care
about what will be configured, compiled and installed, and to skip the
rest. For that, the easiest way seam to patch the configure.ac and
Makefile.am files in each of the projected ebuilds.

The live ebuild that install Gambas from its svn repo is another issue.
Portage make a local copy of the repo, and update it automatically. But
it doesn't use that copy to install gambas, but a copy of that copy,
which imply a fresh install in any case. As it is no way portage can
know the file xyz that was updated into the repo is part of gb.qt or
gb.db, I will keep the monolithic ebuild. And anyway, I doubt that
live ebuild make its way into portage, maybe into an overlay.

Best,
Dominique

> Regards,
> Tobi
>