Re: [Radiator-devel] cli port

[Tim R. <ti...@ga...>]

On Sat, 24 Aug 2002 16:15:53 -0400
Patrick Mahoney <bo...@in...> wrote:
| Module* (Environment::*)(anything) is a big no-no... There should be
| no object, reference or pointer to a module or a link outside the
| Environment class. The non-virtual Module::add_output_port and
| Module::add_input_port serve that purpose. Every port has its index
| and its name stored in the Module object. We simply need to add
| Module::get_outputport_name(index) and
| Module::get_inputport_name(index).

OK, no problem. So how would we do that?
	str =3D env.get_outputport_name(moduleid, index);
=2E..or:
	str =3D env.get_module(moduleid).get_outputport_name(index);

| Sure, it also avoid the plugins which dont need std to be linked with
| it. But what are the "void* param" (1st of register_plugin) and
| "void*" (1st of add_module) for?

That's a reference for the callback that Environment provides. Because
you can have more than one environment class per process (e.g. multiple
documents open), the static function that Environment passes as a
parameter to register_plugin needs some way of identifying which module
list it's adding to. In the sources I committed, I made this a pointer
to the map of new modules, although it could point directly to the new
modules list.

| > -- Got src/plugins to link to bin/basic.rap instead of lots of .so. Thi=
s
| > resulted in a huge saving of disk space (with gcc each .so was taking u=
p
| > 700KB on disk with symbols included). This also avoids the need for me
| > to maintain one VC++ project per module (VC++ only allows one target pe=
r
| > project).
|=20
| What? Link with bin/basic.rap? Whats a .rap file? ??

It's the name for Radiator Plugin DLLs that lynx and I came up with this
afternoon. :) It's a renamed .so or .dll file.

| > -- Changed .shared rule to .shared.o. This lets us use .d files for
| > sources that will always compile to .shared.o (the include $(OBJS:.o=3D.=
d)
| > doesn't know about .shared but it does know about .shared.o).
|=20
| Wouldnt .pic.so be more representative?

OK, sounds better. As I understand it, C++ code needs to be compiled
differently when linking with PIC ELF in mind rather than static ELF, so
=2Epic.o files are those that have been compiled with the -fpic compiler
switch.

| > -- Put POSIX-specific dlXXX functionality into environment_linux.cpp.
| > The linux part of the string should be set to whatever $(PLATFORM) is
| > set to in make.conf.
|=20
| Hmmm... Wouldnt using the pthread-win32 lib avoid doing that? And if
| we get further into multithreading, well need it anyway...

Well, until we get into more complex threading scenarios (such as
synchronisation), a couple of #ifdef lines is enough to provide
portability between Win32 and pthreads. At least, putting in a bit of
conditional code was more preferable for getting the stuff to run than
tracking down and setting up pthread-win32. I guess using a proper
portable thread library will be inevitable eventually, though.

--=20
Tim Robinson <ti...@ga...>