void bar();
#include <stdlib.h>
#include "foo.h"
void bar()
{
return;
}
#include "../a/foo.h"
int main()
{
bar();
return 0;
}
i686-w64-mingw32-gcc.exe -g -pedantic -Wall -IC:\Code\MinGW\include -c C:\Users\Aleksandr\Code\C++\b\main.c -o Debug\obj\b\main.o
i686-w64-mingw32-g++.exe -LC:\Code\MinGW\lib -o Debug\b.exe Debug\obj\a\Debug\obj\foo.o Debug\obj\b\main.o
i686-w64-mingw32-g++.exe: error: Debug\obj\a\Debug\obj\foo.o: No such file or directory
Afaik 'add files' is for adding source files not linker or lib files. And I'm not sure about your intention for trying to add a '.o' file to your project?I totally agree with you. Should add libs not .o files.
Afaik 'add files' is for adding source files not linker or lib files.Resource (.rc, .res) files can also be added to the project and they appear in the category "Resources" and not "Others", despite the fact that .res is already compiled and only need to link. But while it's ok with .rc, with .res is the same as with the .o file.
And I'm not sure about your intention for trying to add a '.o' file to your project?The main reason for this is that the dialogue "Add Files..." uses the default mask "All files (*.*)", While the mask "Only supported types" does not exist. Which makes it possible to consider adding these files possible. The same happens in the dialog "Add files recursively...".
I totally agree with you. Should add libs not .o files.I replaced object (.o) file with library (.a) file, but the problem remained. C::B when linking still adds to the path an unnecessary prefix instead use a relative or absolute path.
Those issues might be bugs in CB but still adding an object file '.o' by 'add files' dialogue doesn't make sense. If you are trying to add a library file or such, you should use the linker settings to accomplish that. Or else AGAIN what is your intention in trying to add an '.o' file to a project?And I'm not sure about your intention for trying to add a '.o' file to your project?The main reason for this is that the dialogue "Add Files..." uses the default mask "All files (*.*)", While the mask "Only supported types" does not exist. Which makes it possible to consider adding these files possible. The same happens in the dialog "Add files recursively...".I totally agree with you. Should add libs not .o files.I replaced object (.o) file with library (.a) file, but the problem remained. C::B when linking still adds to the path an unnecessary prefix instead use a relative or absolute path.
If you are trying to add a library file or such, you should use the linker settings to accomplish that.I am not trying, C::B allows me to do it. And yes, I know it and now I'm using this method.
Or else AGAIN what is your intention in trying to add an '.o' file to a project?Well, I'll try to explain it clearly.
And finally, what would you advise if I have added to the project .res file, and not an .o file? Since when it is added to the project, the symptoms are the same.RES files should work fine. If they don't please post a build log, exact steps to reproduce or even an example project.
About the object file: Probably it is a bug, but you'll have to wait for someone familiar with the build system to answer.Yes, its a bug. What <you can do as another workaround is to put it to the additional linker options.
@Morten can you confirm this is bug, expected behaviour or something that a user should not do?
RES files should work fine. If they don't please post a build log, exact steps to reproduce or even an example project.
#include <windows.h>
int WINAPI WinMain (HINSTANCE hThisInstance, HINSTANCE hPrevInstance, LPSTR lpszArgument, int nCmdShow)
{
return 0;
}
i686-w64-mingw32-g++.exe -Wall -O2 -IC:\MinGW\include -c C:\Users\Aleksandr\Code\C++\a\main.cpp -o release\obj\main.o
i686-w64-mingw32-g++.exe -LC:\MinGW\lib -o release\a.exe release\obj\main.o release\obj\res\resource.res -static -s -mwindows
i686-w64-mingw32-g++.exe: error: release\obj\res\resource.res: No such file or directory
Process terminated with status 1 (0 minute(s), 4 second(s))
1 error(s), 0 warning(s) (0 minute(s), 4 second(s))
2. Use a static library. I don't know why do you think it is bigger in size, but it is not or at least in is not by much. A static library is just an ar archive containing object files and an index.
Correct me if I'm wrong.You're wrong 50%. I'm not sure what is the default behaviour, but linkers can remove unused functions and code these days.
Yes, its a bug.Fixed in trunk.
Why don't you just add the corresponding source files from the library sources to your project? Then you will have only the needed part of your library in your project.
Fixed in trunk.
But no it is not implemented.
You can add the object file manually in the other linker options, but I don't see how this is a problem or how this is confusing.
No one is forcing you to put anything there, but if you need to pass something special to the linker you can do it.
Why compiling a SINGLE source file twice bothers you so much considering it won't even be compiled again when there is no change to it?Why don't you just add the corresponding source files from the library sources to your project? Then you will have only the needed part of your library in your project.
As I wrote before, it does not need to compile. Why do the same job twice?
Well, your proposal is just another way. You can come up with some exotic such as symlinks or something more sophisticated. But ask a question. Why when linking, you think some objects as a given, and others as wrong? Are they bad or guilty? ;-)
The library case was not implementeby me on purpose.instead a warning message will occur if you try. Libraries have to be added through the linker options as the order matters here which cannot be correctly computed otherwise. Adding libraries via"add file"simply makes no sense.
Why compiling a SINGLE source file twice bothers you so much considering it won't even be compiled again when there is no change to it?