Building a self-dependant library file

[cu2nite]

I've written a sub-component using glib libraries which will eventually be used in a larger program in windows.

Glib is rather troublesome to install in windows and I've been asked to package my sub-component into a self-dependent library.

I'm using Visual Studio 2005, and I've built both Static libraries and DLL. Trouble is, my header file still contains "#include glib-object.h" (since I’m using those libraries in my source).

Now when I try to implement my sub-component in an environment that does not have glib libraries installed, VS tries to find “glib-object.h” since there is a “#include”, and can’t find it (since I removed glib libraries).

Is there anyway to build my library so my sub-component can be used independent of Glib?

My header file looks like this:

#ifndef TextFileConverter_h
#define TextFileConverter_h

#include <glib-object.h>
#include <iostream>

class CTextFileConverter
{	

public:
	GIOStatus read_line(GIOChannel* fileRead, GString* convRead);
	int convert_to_utf8(char filepath[],char destinationPath[]);
	int replaceEnd(char filePath[],char destinationPath[], char replace[], char with []);
	//replaces "replace" with "with"
	int unix_to_win(char filePath[],char destinationPath[]);
	int win_to_unix(char filePath[],char destinationPath[]);
};

#endif 

[Duthomhas]

I have never had problems with GTK+ on Windows. That said, I think you are working both ends against the middle here. You must either build against glib or not. You can't do both.

If your public interface uses glib entities, then your component's user must have glib installed to use your component. So in order to satisfy the requirement, you must remove glib from your component's public interface. For example:

#ifndef TextFileConverter_h
#define TextFileConverter_h

#include <iostream>
#include <string>

class CTextFileConverter
{
public:
	typedef enum
	{
		IO_STATUS_ERROR,
		IO_STATUS_NORMAL,
		IO_STATUS_EOF,
		IO_STATUS_AGAIN
	} IOStatus;

	// Methods to get an open file channel
	bool open_file( const char* filename );
	bool attach_fd( int fd );
	...
	// Methods to undo them
	void close_file();
	void detach_fd();
	...

	IOStatus read_line( std::string& destination );
	int convert_to_utf8( const std::string& filePath, std::string& destinationPath ) const;
	int replaceEnd( const std::string& filePath, std::string& destinationPath, const std::string& replaced, const std::string& replacer ) const;
	int unix_to_win( const std::string& filePath, std::string& destinationPath ) const;
	int win_to_unix( const std::string& filePath, std::string& destinationPath ) const;

private:
	void* data;
};

#endif 

I've made a few modifications.

1. IOStatus is basically a GIOStatus. But the people using your library don't need to know that. Nor do they need to install GTK+ headers.

2. The GIOChannel object is hidden away. Unless there is also other state data you want to keep, you can just cast the data pointer to address a GIOChannel. Keep in mind that your object is now responsible with newing and deleteing the GIOChannel object itself. In order to do this, I also introduced methods to initialize and finalize the file converter. It might be worth turning those methods into constructor(s) and destructor(s).

Of course, this is only an example. Make the initializers/constructors the way you need them --just keep the GIOChannel you are using out of view.

3. Use standard string objects instead of GStrings and char*s. This gives the user a lot more flexibility: for example, he can call convert_to_utf8 with a char*, a const char*, a string, a const string, a temporary, etc. (The destination path must always be a string though...)

4. Make sure that your object is "const correct". Methods which don't modify your object are properly marked as const, as are argument references which don't modify their source data. This makes your object more usable.


Now you can compile your DLL using glib, and distribute just the GTK DLL(s) and your own DLL with the above header.

Hope this helps.

[cu2nite]

Thank you very very much.

This helps a lot. I've been trying to package my piece of code for ages mucking around with visual studio.

I'll try this out now, and "const correct" my code =).