|
|
Home » Developing U++ » U++ Developers corner » Autotool support by Upp
Autotool support by Upp [message #8636] |
Thu, 22 March 2007 09:50 |
fallingdutch
Messages: 258 Registered: July 2006
|
Experienced Member |
|
|
I would like to add a way to create Makefile.am's for autotools in Upp so the source release will be more portable.
I thought of a Makefile per Package:
So eg Core gets a Makefile.am and CtrlLib etc
which will output a Library eg noinst_LIBRARIS=Core.a
Core_a_SOURCES= ....
Then the Packages just will have to use the libraries like bin_PROGRAMMS=theide
theide_SOURCES=...
theide_LDADD=../Core/Core.a
For me it is still a problem how to deal with .icpp files.
Mirek introduced them to be files that always have to be recompiled (mostly files including language stuff or database definitions etc) so there should be a way to compile them *every* time and include the objects into the source.
Information/Code/Suggestions etc are very welcome,
Bas
|
|
|
|
Re: Autotool support by Upp [message #8652 is a reply to message #8636] |
Thu, 22 March 2007 17:07 |
|
mirek
Messages: 13975 Registered: November 2005
|
Ultimate Member |
|
|
fallingdutch wrote on Thu, 22 March 2007 04:50 | For me it is still a problem how to deal with .icpp files.
Mirek introduced them to be files that always have to be recompiled (mostly files including language stuff or database definitions etc) so there should be a way to compile them *every* time and include the objects into the source.
|
This is not quite correct.
.icpp files are guaranteed to be included in the final executable.
The problem to solve is that build process tries to minimize the size of executable by not including stuff that is not referenced. First level of this optimization is to link only those objects from library that are referenced. Well, most accurate definition is that in release mode, package are build into .lib (or .a) files first, so that unused .obj (.o) are elimintaed.
So far so good, but quite common trick in U++ is to register modules using global constructors (usually using INITBLOCK macro). E.g. image decoders register themselves so that "LoadAnyFile" can use all possible decoders to load image files. But adding global constructor unfortunately does not make .obj referenced, therefore linker is still free to eliminate it, effectivily eliminating the whole image decoder.
We have struggled with this issue for some time and then decided to tweak build process to solve this problem - .icpp files are simply not put into .lib, but are always linked as .obj. This ensures they are never eliminated from the target.
But no, you do not need to recompile them every time. You just need to not put them into library and link .obj directly.
Mirek
[Updated on: Thu, 22 March 2007 17:07] Report message to a moderator
|
|
|
Goto Forum:
Current Time: Thu Apr 25 19:06:27 CEST 2024
Total time taken to generate the page: 0.05904 seconds
|
|
|