|
|
|
Home » Developing U++ » Releasing U++ » U++ as .lib
|
|
| Re: U++ as .lib [message #11651 is a reply to message #11648] |
Thu, 20 September 2007 15:28   |
sergei
Messages: 94
Registered: September 2007
|
Member |
|
|
| luzr wrote on Thu, 20 September 2007 15:07 |
I would like to discuss all options and problem for releasing U++ as .lib.
My take (Sergei will disagree, but that is what discussion is for:):
Release simple .lib files for MSVC and MINGW (later perhaps package them for Dev-C++ and CodeBlocks).
Release files are just that - release files.
Debug files would be without debug info with assert or perhaps with lines info only to reduce the size.
It would have to come with at least part of sources too.
I will add "file edit mode" to theide so that users of other environments have a chance to edit .iml / .lay and perhaps even .tpp.
I would use theide and some custom program to build libs... Actually, I think I can extend our current release code ("MakeInstall") to generate all .libs for Win32 as part of standard release process...
(OK, the only funny part about all this is that .lib package will be longer 
Hm, an idea: As it seems logical to ship theide with it anyway (as .lay and .iml editor), may the libraries could be built after the installation using theide?
Mirek
|
Actually, I mostly agree. Without a lib for release mode, penalty would be either huge build times (5-10 mins easily) or moderate EXE size increase (due to SCU). However, my idea was to provide an easy way for users to build the lib. That's a common way in open-source cross-platform projects, and it would remove the need to maintain up-to-date built libs for several compilers. There might be a compiler we're not aware of / don't support, and yet works with U++.
File edit mode would be great - just associate all these files with TheIDE.
IMHO debug libs aren't necessary - better to just use the sources (especially if you intend to make changes to U++). + what's the size of a debug lib, if release lib is 10MB? But that's just my opinion 
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: U++ as .lib [message #11711 is a reply to message #11704] |
Sun, 23 September 2007 11:04 |
 |
mirek
Messages: 14257
Registered: November 2005
|
Ultimate Member |
|
|
| cbpporter wrote on Sun, 23 September 2007 04:19 |
And I think it would be very useful to have an article on exactly how BLITZ works, what do you have to do to achieve it and why is it faster. Maybe other projects could benefit from it
(like at my work place where the slightest modification in a file requires a 1-2 minute rebuild).
|
Hm, in ToDo for eons.
OK, so quick BLITZ overview:
First, BLITZ processes packages (not the whole program) - each package can have a single BLITZ block.
Only .cpp including files with guards (#ifdef H... #define H) can qualify to be part of BLITZ block. Alternatively, you can force inclusion by #pragma BLITZ_APPROVE (also for header) or exlusion by #pragma BLITZ_PROHIBIT.
AND only files older than one hour qualify for BLITZ block. (Because you do not want files you work on to be in BLITZ block).
Also, the whole package can be excluded based on .upp settings.
Then files are scanned for any #defines, these are undefined at the end of file. BLITZ block is in fact a file generated into output directory that include all BLITZ approved files and gets compiled instead (it is named $blitz.cpp, you can check the output directory for details).
Now a dirty trick:
#ifdef flagBLITZ
#define MK__s MK__s_(COMBINE(BLITZ_INDEX__, __LINE__))
#else
#define MK__s MK__s_(__LINE__)
#endif
Blitz block defines BLITZ_INDEX__ for each file, in order to give a library code chance to define unique static variable names...
OK, I believe that is all about the BLITZ magic:)
Mirek
|
|
|
|
|
|
| Re: U++ as .lib [message #11715 is a reply to message #11648] |
Sun, 23 September 2007 16:46 |
sergei
Messages: 94
Registered: September 2007
|
Member |
|
|
I might have a very old computer, depending on what you consider an old one. I'm on P4 - 3.0 GHz, Cedar Mill (duh, the last one before Core Duo), FSB 800 MHz, 2GB RAM - CL5, 667 MHz. Old WinXP SP2 setup.
As I said you can recompile the libs rather easily. 20 mins for debug+release in MSVC. The huge times in MinGW are because I didn't use precompiled headers. If I did it would be about 20 mins too. Long times for MSVC/release and MinGW/debug with the libs are because the libs are huge. For MSVC that's rather surprising, shouldn't release be small...
If you want to compare my times to your computer, here are my times for UWord:
TheIDE / 708dev2b / MinGW (bundled) / debug : 15.1MB / 1:24
TheIDE / 708dev2b / MinGW (bundled) / optimal : 2.2MB / 3:04
SCU / lib times aren't that awful now, right? Remember I'm always posting full rebuild times, which are probably only necessary for the first build.
I could try debug libs without full info (that means flagDEBUG but no flagDEBUG_FULL, right?). Yet I still favor SCU more than debug lib (step in, quick modify and rebuild).
|
|
|
|
|
|
| Re: U++ as .lib [message #11718 is a reply to message #11717] |
Sun, 23 September 2007 19:30 |
sergei
Messages: 94
Registered: September 2007
|
Member |
|
|
| luzr wrote on Sun, 23 September 2007 19:04 |
| sergei wrote on Sun, 23 September 2007 10:46 |
If you want to compare my times to your computer, here are my times for UWord:
TheIDE / 708dev2b / MinGW (bundled) / debug : 15.1MB / 1:24
|
0:26
E4300 @ 2.7Ghz, 2 GB RAM
Anyway, this is with new MinGW as compared to 708dev2b (4.x GCC is faster).
BTW, fastest time with MSC7.1 is 16s. That is quite acceptable for full U++ GUI rebuild
Mirek
|
In other words my comp is slow 
That means that you could, like, divide my times by 3 
I just realized that flagDEBUG_FULL makes no difference (it's really not used). I've disabled PDB, now debug is MSVC is 26MB (vs 78MB). Still too large. But I've found the reason for 353MB release lib - link time whole program optimization (enabled by default). Without it the size 26MB (again, too large).
|
|
|
|
|
|
|
|
| Re: U++ as .lib [message #11725 is a reply to message #11722] |
Sun, 23 September 2007 21:34 |
|
mirek
Messages: 14257
Registered: November 2005
|
Ultimate Member |
|
|
| sergei wrote on Sun, 23 September 2007 14:05 |
| luzr wrote on Sun, 23 September 2007 19:55 |
26MB does not need to too large - try to zip it...
Anyway, check the flags you are using for debug info...
Mirek
|
I use no debug info. There's PDB, C7, ... I chose no debugging symbols.
ZIP is 6MB. OK, not large. But there would be one for debug, one for release, + maybe a separate set for multithreaded. And what about SQL? Include/exclude (currently excluded)?
|
Well, yes. That is why it is so much complex problem... Told you at the beginning, right?
I mean, I really would like to have .lib versions. The trouble is that I do not really know how to do that
Looks like a simple job, but in reality, there is a lot to be solved.
Mirek
|
|
|
|
| Re: U++ as .lib [message #11727 is a reply to message #11725] |
Sun, 23 September 2007 21:59 |
sergei
Messages: 94
Registered: September 2007
|
Member |
|
|
| luzr wrote on Sun, 23 September 2007 21:34 |
| sergei wrote on Sun, 23 September 2007 14:05 |
| luzr wrote on Sun, 23 September 2007 19:55 |
26MB does not need to too large - try to zip it...
Anyway, check the flags you are using for debug info...
Mirek
|
I use no debug info. There's PDB, C7, ... I chose no debugging symbols.
ZIP is 6MB. OK, not large. But there would be one for debug, one for release, + maybe a separate set for multithreaded. And what about SQL? Include/exclude (currently excluded)?
|
Well, yes. That is why it is so much complex problem... Told you at the beginning, right?
I mean, I really would like to have .lib versions. The trouble is that I do not really know how to do that
Looks like a simple job, but in reality, there is a lot to be solved.
Mirek
|
That's why SCU is cool - no libs required
But really, why not let the users build the libs by themselves? It shouldn't take more than half an hour, worst case. Plus they'll select whatever packages they want, multithreaded or not, if they want SQL they'll have SQL installed so it will work. Two builds - debug and release, and no extra large downloads.
|
|
|
|
|
|
| Re: U++ as .lib [message #11730 is a reply to message #11728] |
Sun, 23 September 2007 23:12 |
sergei
Messages: 94
Registered: September 2007
|
Member |
|
|
| luzr wrote on Sun, 23 September 2007 22:21 |
Yes! Using makefiles?
I guess the real problem is that there are so many options and no really good solutions
Mirek
|
AFAIK makefiles are compiler/system dependent. There is such a thing as bakefiles, but I've never used them (actually I did, when I tried to build VCF, but it didn't work ).
Many options - yes. Good solution? Well, IMHO what I've posted in the other thread is fine. You just have a folder (UppLib), tell the user to use whatever compiler he wants, just add all files in the folder to a static lib project and build. Problem would appear only if the user has a compiler but doesn't have an IDE. But then, use TheIDE 
This solution is flexible - a premade makefile would probably include a preset set of packages, or would be tricky to code to enable options. But with a folder of source, user could modify pkggen.txt, select whatever packages he wants, use the required flags with pkggen.exe and get a folder of sources HE WANTS. I might be reinventing the bakefiles/makefiles wheel, but this works.
I understand that you really want libs, but I wouldn't discard SCU for debug. It proved to be extremely useful when I was modifying U++ source (those tiny bugfixes). TheIDE debugger didn't work as expected, but with MSVC + SCU I was able to fix something and test it within half a minute. Guess I'm in the minority (people who modify U++ would prefer TheIDE), but still... It could be marked "for advanced users"
|
|
|
|
|
|
Goto Forum:
Current Time: Fri May 09 21:57:58 CEST 2025
Total time taken to generate the page: 0.04329 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
. Any free/opensource alternatives?
