On Fri, 2013-06-21 at 13:52 +0200, Éloi Rivard wrote: > > For readability and coherence, I think program options parsing should > not be done in view.c.
this arose when introducing scheme, I tried to keep the scheme headers to just one file, anticipating that they could destabilize denemo's code - we had an example of this recently, when Jeremiah introduce a foreign header file (sffile.h) which defined things already defined in Denemo. However, view.c is monstrously overloaded, (my fault :( ) Richard > > It seems that scm_with_guile() exists with 1.8 : > https://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Guile-Initialization-Functions.html#Guile-Initialization-Functions > > > > 2013/6/21 Richard Shann <[email protected]> > On Fri, 2013-06-21 at 13:42 +0200, Éloi Rivard wrote: > > Is there a reason to use scm_boot_guile() instead of > scm_with_guile() > > in main ? > > > I am not sure all these variants existed when I got guile > working from > inside C. Indeed, I am not sure which ones are available in > guile 1.8. > Do you see some advantage to using something different? > > Richard > > > > > > > > > > > 2013/6/4 Richard Shann <[email protected]> > > I've just tested this out and it seems to be working > fine :) > > > > Richard > > > > > > On Tue, 2013-06-04 at 16:57 +0200, Éloi Rivard > wrote: > > > On the split branch, evince is now enable by > default, but no > > more > > > mandatory. So now I can compile denemo with gtk2 > and make > > some larger > > > tests. > > > > > > > > > > > > 2013/6/4 Éloi Rivard <[email protected]> > > > I pushed the branch split where the evince > part of > > print.c is > > > now in printview.c . Could you tell me if > it is good > > for you ? > > > > > > > > > > > > 2013/6/4 Richard Shann > <[email protected]> > > > On Tue, 2013-06-04 at 13:23 +0200, > Éloi > > Rivard wrote: > > > > > > > > 2013/6/4 Richard Shann > > <[email protected]> > > > > On Tue, 2013-06-04 at > 11:40 +0200, > > Éloi > > > Rivard wrote: > > > > > > > > > Tools are now built > when you run > > make. > > > > > > > > > > > > I have run my usual make > (in a > > parallel > > > directory to the > > > > source > > > > directory) and it ran > ok, > > generating the > > > tools in a parallel > > > > directory > > > > to the tools directory > containing > > the source > > > code of the > > > > tools. > > > > > > > > > > > > > > What do you think of > > automatically > > > call ./generate_source > > > > > and ./extract_scheme > before > > compiling the > > > src directory ? > > > > > > > > > > > > This has to be done in > the source > > directory > > > not the build > > > > directory > > > > though. > > > > You mean in order to make > extract_scheme > > work ? > > > > > > and generate_source, they have to > be > > executed at > > > particular places in > > > the source tree, not a build > directory. > > > > > > > > > > > > How would you determine > the > > dependencies? > > > > autotools are very convenient > for this. It > > is easy > > > to set up > > > > dependencies between targets by > playing > > with > > > Makefile.am files > > > > > > > > > In this case a new *.xml file > somewhere in > > the > > > hierarchy below menus > > > should trigger a re-run of > extract_scheme. > > It will be > > > good if it can be > > > done. > > > > > > Richard > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Éloi Rivard - [email protected] > > > > > > « On perd plus à être indécis qu'à se > tromper. » > > > > > > > > > > > > > > > -- > > > Éloi Rivard - [email protected] > > > > > > « On perd plus à être indécis qu'à se tromper. » > > > > > > > > > > > > > > > > > -- > > Éloi Rivard - [email protected] > > > > « On perd plus à être indécis qu'à se tromper. » > > > > > > > > > -- > Éloi Rivard - [email protected] > > « On perd plus à être indécis qu'à se tromper. » > _______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
