Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
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
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

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 Wink 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 Wink

Sorry for the long boring post and thanks for reading it all the way down here Very Happy

Best regards,
Honza


Previous Topic: MSC10 and MSC10x64 build flags
Next Topic: compilation error on ubuntu 11.04 (glibconfig.h)
Goto Forum:
  


Current Time: Thu Mar 28 10:14:45 CET 2024

Total time taken to generate the page: 0.01012 seconds