Thread: Separating modules into different components

Hey,

I'm trying to separate some commonly used modules - for instance, a full socket server.

I've put everything into individual folders and am creating Makefiles for each folder (this is a Linux server, btw). The problem is, the Server component needs to call an object which is used in every project as the 'event handler' so to speak - an event processing the command the client has said. Not only that, but occasionally the programs logic will need to send commands to the client at its will - not initiated by a client event (such as a regular ping, or a new message).

I want to somehow create - and preferably compile - the entire server module in to .o files ready for full linking to the project in question. Then, be able to iteratively go through the recompile all projects that rely on said Server module without editing them - AND without having the server need to be modified for each project.

Is there another way other than a common 'interface' object that must be created to talk between the Server and the rest of the program? This would require a class within the Server folder that can be used for communication between Server and the program. Also, is there a way to compile just classes that have no implementation (ie, are missing a main() function)?

Basically - is my logic here correct or is there some super-elegant way I could be doing this?

Cheers!

I want to somehow create - and preferably compile - the entire server module in to .o files ready for full linking to the project in question. Then, be able to iteratively go through the recompile all projects that rely on said Server module without editing them - AND without having the server need to be modified for each project.

So you want to make libraries. A general pattern for the makefile would be:

Code:

SRCS = serv1.c serv2.c serv3.c
OBJS = $(SRCS:.c=.o)

SERVER = libserv.a

libserv.a: $(OBJS)
        ar ruvs $@ $?

clean:
        rm -f $(OBJS) $(SERVER)

Each library you want to create will have its own makefile which would look something like that. Obviously a real makefile is more complex, but that's the meat of it.

Thanks, brewbuck.

Libraries - I've heard of these used with regards to linking, so that makes sense - cheers, gives me something to look up.

Tell me - how would I then go about using that libary within another project? Just by including it in -lserver.a ? Or some other syntax? (As the only library I'm really familiar with is -lpthreads - so perhaps the syntax is different from user-defined libraries).

Also - how do I solve the problem that the server somehow has to have (2-way) communication with the rest of the program? What would the interfaces be there, or do I simply have to create an interim object and communicate between them, like:

Code:

class Server
{
//....
public: void SetClient(ClientObject * client){...}
private: void ReceivedData()
{
 m_ClientObject->SendData(data);
ClientObject * m_ClientObject;
}
//...
};

And then - upon creating an instance of Server - set the client for 2-way communication?

Cheers

Originally Posted by MrSparky

Tell me - how would I then go about using that libary within another project? Just by including it in -lserver.a ? Or some other syntax? (As the only library I'm really familiar with is -lpthreads - so perhaps the syntax is different from user-defined libraries).

Close -- you use "-lserver" not "-lserver.a". You leave the "lib" off the front and the ".a" off the back. And the code which uses the library will probably need access to the relevant header files.

Also - how do I solve the problem that the server somehow has to have (2-way) communication with the rest of the program?

Typically a library has none or very limited "two way" communication. Communication can occur via callbacks, returns values, or exceptions. If the library actually depends on symbols from some other library, then these two libraries are said to be "coupled" and conceptually, they might actually be better represented as a single library.

One of the more difficult parts of library design is coming up with a way for "user code" (i.e., the code which calls your library) to communicate with it. It takes practice, and lots of failure, before you start getting the hang of it.