Static libraries

[BOURGER]

Hello,

I work with Windows XP SP3 and CodeLite 6.0.
I want to make a static library with some utilities written in C.
I opened a new project called Utils and I added some files in the src project folder.
All would be OK either in Debug mode or in Release mode, except for the extension of the object files, as can be seen in the BuildLog.txt file listed below:

C:\WINDOWS\system32\cmd.exe /c "F:/MinGW-4.8.1/bin/mingw32-make.exe -j2 -e -f Makefile"
----------Building project:[ Utils - Debug ]----------
mingw32-make[1]: Entering directory 'F:/Tries_CL/Utils'
F:\MinGW-4.8.1\bin\gcc.exe -c "F:/Tries_CL/Utils/getargs.c" -g -o ./Debug/getargs.c.o -I. -I.
F:\MinGW-4.8.1\bin\gcc.exe -c "F:/Tries_CL/Utils/options.c" -g -o ./Debug/options.c.o -I. -I.
F:\MinGW-4.8.1\bin\gcc.exe -c "F:/Tries_CL/Utils/printmsg.c" -g -o ./Debug/printmsg.c.o -I. -I.
F:\MinGW-4.8.1\bin\gcc.exe -c "F:/Tries_CL/Utils/reprterr.c" -g -o ./Debug/reprterr.c.o -I. -I.
F:\MinGW-4.8.1\bin\gcc.exe -c "F:/Tries_CL/Utils/skipargs.c" -g -o ./Debug/skipargs.c.o -I. -I.
F:\MinGW-4.8.1\bin\gcc.exe -c "F:/Tries_CL/Utils/wstrings.c" -g -o ./Debug/wstrings.c.o -I. -I.
F:\MinGW-4.8.1\bin\ar.exe rcu ./Debug/libUtils.a @"Utils.txt"
mingw32-make[1]: Leaving directory 'F:/Tries_CL/Utils'
0 errors, 0 warnings

Instead of the output file "getargs.c.o" I supposed I would get the file "getargs.o".
And I do not understand why the final option -I. is written twice.

I read the Utils.mk file and the first lines are:
##
## Auto Generated makefile by CodeLite IDE
## any manual changes will be erased
##

So I thing that something has to be changed in the ".mk" file generation, but where ?

[eranif]

Instead of the output file "getargs.c.o" I supposed I would get the file "getargs.o".

No. This is perfectly fine, this is how codelite named the object files: full file name + .o suffix

And I do not understand why the final option -I. is written twice.

This is also not a problem at all. I guess its there twice because of the global options (project settings -> global settings -> additional include paths), if you remove the '.' from that line it will go away
Again, it has no affect on whatsoever on the output

except for the extension of the object files

How does this cause a problem? what you create a static library you link against it, not against the objects inside it (i.e. you don't need to specify their name, just the library name)

Eran

[BOURGER]

Hello,

I come from the UNIX world and I read a lot of books where I see that a "foo.c" generates a "foo.o" object and then a "foo" executable.
I read that for example in the "Kernighan Richie C" reference or in the "C in a nutshell"
I thought it was a "de facto" standard.
It used to work too with Visual Studio and of course, this rule does not apply. But this is Microsoft ....

[eranif]

I come from the UNIX world and I read a lot of books where I see that a "foo.c" generates a "foo.o" object and then a "foo" executable.
I read that for example in the "Kernighan Richie C" reference or in the "C in a nutshell"
I thought it was a "de facto" standard.

In previous releases of codelite, this was indeed the object name (filename+.o)
However, consider this simple project which consists of 2 files:

file.cxx
file.cpp

Using your method both files generate the same object file: "file.o", while codelite will generate "file.cxx.o" and "file.cpp.o" which is the desired behavior
Note that other wide spread tools are also using this method (e.g. CMake)

In fact, no one really cares about the object names, as long as the final output works

Eran