Home » U++ TheIDE » U++ TheIDE: Compiling, Linking, Debugging of your packages » "Accept flags" behavior
"Accept flags" behavior [message #34179] |
Fri, 28 October 2011 14:44 |
|
Hi,
I've been once again playing with the makefiles and stuff... When I implemented the .FLAG feature I come to a point where my builds failed with this error for GUI apps when .USEMALLOC is specified: Linking bin/ide
CtrlLib/GCC.GUI.LINUX.POSIX/CtrlLib.a(CtrlUtil.cpp.o): In function `Upp::MemoryProfileInfo()':
CtrlUtil.cpp:(.text+0xce7): undefined reference to `Upp::MemoryProfile::MemoryProfile()'
CtrlUtil.cpp:(.text+0xd04): undefined reference to `Upp::PeakMemoryProfile()'
collect2: ld returned 1 exit status
Upon closer inspection of the reported functions I found two things: 1) CtrlLib needs to be build with USEMALLOC when Core is compiled with this flag, but it doesn't have it in its acceptflags field and 2) Theide handles the acceptflags field differently than I thought.
The first point is quite straightforward to explain, when U++ memory management is used, then there are memory profiling widgets defined in CtrlLib, but with USEMALLOC it doesn't make sense to define them and flagUSEMALLOC macro is used to determine which is the case.
The second point is something I remember actually hitting a long time ago, but I already forgot about it, so maybe it is even mentioned here on the forum somewhere. When theide evaluates dotted flags, like .USEMALLOC, it assigns it not only to main package and packages that have it in accept fields (in this case only Core), but also to all packages that use it. As far as I know this is in vast majority of cases totally unnecessary. So far I found only one situation (the one described above) where there is a difference. And this one case is easily solved by adding USEMALLOC into acceptflags field of CtrlLib.
I know that asking for changing theide behavior has a little chance to succeed, but hey, it would be nice if it actually did the rebuilds in more effective way when dotted flags are involved If someone's going to argue about backwards compatibility: Yes, it could break some projects, but I think this is used very rarely and it will be really easy to fix (just drop the dot or add a flag to few more accept fields...) so backward compatibility is not much of an issue. And even if it is decided to not change theide, could we add USEMALLOC to acceptflags field of CtrlLib? Just to make lives simpler for the people trying to build U++ apps with alternative build systems
Sorry for the long boring post and thanks for reading it all the way down here
Best regards,
Honza
|
|
|
Goto Forum:
Current Time: Thu Mar 28 10:14:45 CET 2024
Total time taken to generate the page: 0.01012 seconds
|