| With which files does Eclipse start to compile and how to change it [message #1385907] |
Thu, 12 June 2014 08:30  |
 Frank Ihle
Messages: 2
Registered: June 2014 |
Junior Member |
|
|
I'm importing a different project into mine - that has not been properly coded when it comes to include files. When compiling, it generates random errors that some functions/variables etc. are not defined.
I believe this is because of a wrong compile/include order, because the missing declarations are in files that are actually part of the project.
So how does Eclipse (CDT) make it ? Is it aphabetical order? How can I change it, do I really have to write my own makefile, or is there a way to force the compiler to start with a specific file ?
Kind Regards
[Updated on: Fri, 13 June 2014 08:46] Report message to a moderator |
|
|
|
|
| Re: With which files does Eclipse start to compile and how to change it [message #1401655 is a reply to message #1386254] |
Wed, 16 July 2014 00:01  |
Henning Riedel
Messages: 310
Registered: July 2009 |
Senior Member |
|
|
Am 16.06.2014 10:19, schrieb Frank Ihle:
> That's what I said, that code isn't very properly designed - but it's
> working when compiled on it's own. So somehow I have to change the make
> order. It's working when I write my own makefile: that's basically the
> one that Eclipse has created and changed the order there, but if i do it
> like this I have to waive the nice eclipse-makefile-wizzard. I would
> appreciate, if this will become a feature some day
The thing is, you give so many information, it is hard to answer here.
a) What kind of project is it .. C or C++?
b) At least in a C project, each C file is a translation unit for
itself. So, it does not matter at compiling, if a.c is compiled before
b.c. The linker might bail out, because of missing symbols.
Surely, there'll be problems regarding wrong includes, in case of
undefined defines/ macros or unknown types. But, processing includes is
done by the preprocessor, in a usual stupid way of "copy/paste" of the
header contents at the place of the #include statement.
c) In case of maybe C++, if your build depends in stuff like precompiled
headers, this might be a problem, but I can't comment here, since my C++
experience is about a decade ago now.
d) In case of linking problems related to finding symbols in libs, it is
well known (usually), that the order of libraries is important, unless
you can tell your compiler to search through libs multiple times.
e.g. gcc -o output main.o a.o b.o -llib1 -llib2 -llib3
libraries here are searched for symbols in the order lib1 -> lib2
->lib3. But you must make sure, that lib3 does not depend on symbols in
lib1. Or you must set lib1 at the end of the library dependencies. The
compiler usually will not scan lib1 again, after it has done it once.
|
|
|
Powered by
FUDForum. Page generated in 0.02968 seconds
] 
Search
Help
Register
Login
Home
