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

[Benoît Minisini]

Le 01/05/2012 13:27, Bruce Bruen a écrit :
> 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
>

I don't like any of those solution at the moment.

And if I define a compilation constant that will tell the compiler if we 
are making an executable or not? That way, you will just have to add a 
"#If Executable" (or something like that) to compile or not compile the 
startup function ?

-- 
Benoît Minisini