[Gecode] Attempt at building libraries

[Christian Schulte]

Dear all,

while solution 3 appears to be most appealing, I don't really like it as it
is an overkill (at least for now).

Let's just settle for 2). Should be very easy, just have an object of a
board type which does a noop. So that will not incur any overhead.

Cheers
Christian

--
Christian Schulte, http://www.imit.kth.se/~schulte/ 

-----Original Message-----
From: gecode-bounces at ps.uni-sb.de [mailto:gecode-bounces at ps.uni-sb.de] On
Behalf Of Guido Tack
Sent: Monday, March 22, 2004 3:03 PM
To: gecode at ps.uni-sb.de
Subject: [Gecode] Attempt at building libraries


Hi!

I have tried building gecode using automake/autoconf. This works perfectly, 
except for one problem: The way how variable modification boards are
handled. 
This is the only place where we have an indirect link from the kernel to the

variables, because the initialisation of the vmb array is done by the 
variables, and the kernel just iterates over the array. 

In my setup, I build a static library which the executable is then linked 
against. Now if a program only uses int vars, fs/core.o won't be linked into

the binary, resulting in a segfault when the kernel tries to access 
vmb[VTI_FS]. I see three possible solutions:
1) Use a dynamic library instead - all object files are always loaded
2) Initialise the vmb with dummy values
3) Implement a subscription mechanism for variable types: Before first use,
a 	
variable type has to register with the kernel, and the number of registered 
variables and their type ids are handled dynamically

What do you think? I don't know how big the performance overhead of 3) would

be, I guess at least it's a clean solution. On the other hand, 2) should be 
relatively simple to implement.

Guido

-- 
Guido Tack
Programming Systems Lab
http://www.ps.uni-sb.de/~tack
_______________________________________________
Gecode mailing list
Gecode at ps.uni-sb.de http://www.ps.uni-sb.de/mailman/listinfo/gecode