[Gambas-user] About library and component packaging in Gambas 3

[Bruce Bruen]

On Tue, 2012-05-01 at 12:22 +0200, Benoît Minisini wrote:
>  A lot of answers to a lot of stuff, so I'm going to break it up into several posts.

> Le 29/04/2012 06:45, Bruce Bruen a écrit :
> >
> > SUGGESTION: Libraries should not need to have a startup class.  At
> > the moment I "must" include a dummy module to prevent any
> > test-harness code leaking into the user environment (which could
> > cause damage if the library were to be run as a normal gambas
> > executable.)  At the moment the IDE will not let a library be made
> > into an executable or packaged unless it has a startup class.  It
> > would be preferable that projects defined as libraries would not
> > execute via the runtime, that way test harness code could be left in
> > place.  Currently I have to check that the coders have left the
> > startup class pointing to the following:-
> >
> > ' Gambas module file
> >
> > ' Null module to provide a fake startup point
> >
> > Public Sub Main()
> >
> > Error "Please do not run this as a program. It is a gambas library."
> >
> > End
> >
> 
> Mmm. You are right, for libraries the IDE should let you not defined a
> startup class. I will see what I can do.
> 
I think that ("the IDE should let you not defined a startup class") is
an overkill.  What I need is a way to use a startup class in a library
when I'm developing it but when it is packaged the startup class should
be "removeable".

To explain, during development/debug/support for a library, we need to
be able to run it as a normal project through the IDE.  This is what I
meant about "test harnesses".  In general, we have a MMain module in the
library that may, or in fact usually, contains code that lets us enter
method parameter values manually.  This type of code if used by an
ill-advised user could cause great havoc on an underlying database or
the like.

What I would like is a way to manually disable or "turn off" the startup
class when the library project is made as an executable or is packaged.

I suppose that the alternative is to not allow startup classes in
libraries or components and keep changing the project type to "Normal"
when we are debugging/supporting but I can foresee a lot of mistakes if
that route is chosen.  

The way I see it is this.  (Hypothetically) I've just spent some time on
the phone to Mr Jones and it appears that there is, amazingly, a problem
in the xyzzzy library. I open the xyzzy project and using the test
harness code therein I find that we did in fact code a logic error when
some date parameter to a dual timezone function is exactly the date and
time that daylight savings changed in one of the timezones.  ( I kid you
not, this happened recently!)  So I give the problem to the wizkids, er
sorry, my brilliant development team, and they come up with a nicely
tested solution.  

So now all I want to do is turn off the startup class, compile and make
the distributable version and send it out. 

With a bit of thought... maybe what libraries/components need is a
startup class that only works within the IDE...

hmm!

Bruce