CodeLite IDE

Dear,

I have a minor question of using same Codelite projects between Linux and Windows and some gory detail how the mingw differs from gcc and how this difference can best get handled with click-and-drop generated project files.
Lets assume a project which links a shared library "libFunctions.so" to an executable "MainProg". The same sources and Codelite project files are used with Linux and Windows, I share the same repository of version control system.

Basically, my ".so" file is made via

gcc -c ./src/Functions.c -g  -o ./$(ConfigurationName)/Functions.o -I.
g++ -shared -fPIC -o ./$(ConfigurationName)/libFunctions.so ./$(ConfigurationName)/Functions.o -L.

and the executeable is made via

g++ -c ./src/MainProg.cpp -g -O0 -Wall -o ./$(ConfigurationName)/MainProg.o -I./inc -I../Functions/inc
g++ -o ./$(ConfigurationName)/MainProg ./$(ConfigurationName)/MainProg.o -L./lib -L../Functions/Debug -lFunctions

It does well under Linux / Codelite 12 ... 15.

... BUT ...
when using a MinGW compiler under Win / Codelite (msys32 in my case, but apparently this detail does not matter), the Linker would not search for "libFunctions.so" when specifying -lFunctions. Instead, MinGW compiler would search "libFunctions.dll". But the Codelite generated project/makefiles are creating a "libFunctions.so".

Thus, in Windows environment I had to specify this "Post Build" step:

	# copy .so to .dll because MinGW linker expects libXYZ.dll if statically linked -lXYZ, no .so as in linux
	cp $(OutputFile) $(OutDir)/lib$(ProjectName).dll

This additional line fixes the Windows linking problem and does no harm in Linux, except it pollutes my output folder. I hate pollution

Yes, another way would be to specify "-o ./$(ConfigurationName)/libFunctions.dll" in the makefile of the lib, but this entry is maintained by Codelite and the .dll extension would not get linked in Linux, I'd have to fix the inverse problem in Linux' post build step.

So my question #1 is:
Is there a more elegant way to force the ".so" extension to become ".dll" instead, but with still using the Codelite generated project/makefile and with having same project/makefile shared with Linux+Windows? Maybe something like ".$(SharedLibExtension)" or such?

My question #2 is about the ./$(ConfigurationName) which f.i. expands to either "./Debug" or "./Release": I really like using it, because I can easily toggle between full debug build or full release build of a project with linked sub projects. But I hate this lengthy "$(ConfigurationName)" name. Can I myself create an alias like $(Res) which has same meaning (and does not get overwritten by Codelite while maintaining the project files)?

Yes this questions are luxury problems, no urgency. But, hey, I'm using Codelite since years and almost all times all is well. How could I ask more urgent questions?

Cheers,
Modem Man

The linking line is taken from the compiler settings:

settings -> build settings
From the left view, select your compiler and the use the Template tabs.
At the bottom, there is a line that describes what will CodeLite use to link your DLL/SO.

For shared objects, CodeLite is using this:

$(SharedObjectLinkerName) $(OutputSwitch)$(OutputFile) @$(ObjectsFileList) $(LibPath) $(Libs) $(LinkOptions)

You change that and use environment variables here.