| | [ Return to Bugs & Features | Roadmap 2.0 | Post Text | Post File ]
STR #1663
| Application: | FLTK Library |
|---|
| Status: | 5 - New |
|---|
| Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Unassigned |
|---|
| Summary: | ability to compile FLTK as single translation unit |
|---|
| Version: | 2.0-feature |
|---|
| Created By: | PavelVozenilek |
|---|
| Assigned To: | Unassigned |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
[ Post File ]No files
Trouble Report Comments:
[ Post Text ]
| |
| #1 | PavelVozenilek
18:58 May 01, 2007 |
| In my project I add C++ source files into one of few large translation unit (many *.cpp files het included into one .cpp file and this gets compiled). This trick helps me to reduce compilation time (one or two orders of magnitude for a large, Boost heavy application) and I try to use it for every library.
I tried the same with FLTK2.0 and found several things that would need a change. I'll mention few of them here and can publish all those found if there's interest in such feature. Otherwise compiling the FLTK files separately works OK for me (GCC 3.4.2 on Windows)
Things that prevent compileing FLTK as single TU:
1. the symbol 'Rectangle' is used by windows Headers. I needed to prepend fltk:: to every 'Rectangle' used as parameter or local variable, e.g.
void _draw(const fltk::Rectangle& r) const;
2. Several functions are implemented in more than one file: nogroup() or min().
3. Several symbols are used in different contexts: e.g. NOTHING.
4. Macro REPEAT is defined in several files.
5. Symbols as 'small' and 'horizontal' are defined, somewhere, as macros and this clashes with their use elsewhere.
When FLTK 2.0 will be released I'll patch it locally to compile as single TU. If there's interest by developers I may provide details, patches, tests, whatever is needed. It is quite a lot of boring work, however. | |
| |
| #2 | sanel.z
13:49 May 04, 2007 |
| For issue 1. there could be a workaround; instead placing "using namespace fltk" in every .cxx file, whole code could be wrapped inside namespace, like is done for headers (am I catching you correctly ?).
NOTHING/REPEAT should not be a problem; each of them is used by 3 files.
For issue 5. can you give some pointers :) ? | |
| |
| #3 | matt
00:39 Dec 18, 2007 |
| Hmm, the idea of splitting a library into several source files is to actually *reduce* compile time. Sure, if you compile the first time, it will take longer, but once compiled, only the files that changed need to be recompiled, saving a lot of time in the process. Multiple source files also allow for multithreaded compilation or even distributed compilation. A monolithic file can only be compiled by a single CPU while a second ore may be ideling.
I cannot see any benefit for the community in this request. Rather it restricts development inside the source files. | |
| |
| #4 | aivushkin
01:53 Dec 18, 2007 |
| I agree with matt.
This method may be needed in a very special cases
http://www.sqlite.org/cvstrac/wiki?p=TheAmalgamation | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |
FLTK Apps 
