|
|
|
Home » U++ Library support » U++ Library : Other (not classified elsewhere) » Building & using U++ without TheIDE
| Re: Building & using U++ without TheIDE [message #11410 is a reply to message #11395] |
Tue, 11 September 2007 22:16   |
 |
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| sergei wrote on Mon, 10 September 2007 16:35 |
OK, I still don't understand the purpose of icpps. Some have extra includes, some INITBLOCKS and functions. Wouldn't it be easier to make one global function like InitUpp that would do the registers, and call it in GUI_APP_MAIN?
|
Keep in mind that this is modular system. The purpose of .icpp is to register modules that are not known at the time when registration procedure is created.
E.g. you can add new image formats, in the form of plugin package, this way and simply adding this new package to your project makes StreamRaster::LoadFileAny aware of this format.
| Quote: |
I'm working on a static lib project, so empty functions probably don't matter - nothing should be thrown out in static lib.
|
Sure the do matter. Linker only includes .obj from .lib that are referenced. That is the main and the only difference for .icpp - they are linked as .obj so they are always included.
| Quote: |
I actually manged to solve the Lng error (or did I?). t.h was missing NAMESPACE_UPP at top and END_UPP_NAMESPACE at bottom.
|
Means something else is wrong elsewhere: t.h is widely used without this problem.
| Quote: |
#include <TCtrlLib/TCtrlLib.h> (in Geom/Ctrl/GeomCtrl.h)
#include <TCore/TCore.h> (in Geom/Coords/GeomCoords.h)
|
You do not seem to listen...
Please, check UWord example in theide first.
If you are so much afraid about starting theide, ok. There are .upp files in all packages and they create a dependency tree. Check what is really needed for GUI application.
| Quote: |
I removed Geom from project to see if I can continue - then I reached, once again, the INITBLOCK. Assuming I give up modularity, and want to build a single lib containing everything, except from stuff needed only for TheIDE, can I do something about the icpps? I mean, there has to be a nicer solution than using INITBLOCKS in different CPPs so they don't see each other...
|
Rename to .cpp and insert referencing emty function. Call these in main.
| Quote: |
P.S. the documentation is incomplete, how can I know what is used for TheIDE and what isn't? UWord uses only a small subset, e.g. Sql, Web, etc. are part of the library but aren't used.
|
That is correct, but I think you should start with simple. I guess Sql will deserve separate library anyway - in fact, I am not sure how to handle differente RDBMS engines, because many of them require RDBMS clients to be installed. So perhaps each engine will require separate .lib too (but hey, this really is not my problem to solve - we have solved by creating theide, which solves these kinds of problems 
| Quote: |
P.S.2 what do I need to define besides PLATFORM_WIN32? DEBUG? UNICODE?
|
theide, UWord example, Setup/Verbose, see the commandline...
Mirek
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11411 is a reply to message #11399] |
Tue, 11 September 2007 22:21 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| sergei wrote on Mon, 10 September 2007 20:21 |
Followup: without completely understanding why and how INITBLOCK works, I replaced it in icpps with INITBLOCK_(BLK_###), where ### is the name of the file. It worked, and now I'm stuck on:
D:/Dev/0/1/libUpp/Core/Topt.h: In function `void Upp::AssertMoveable0(T*) [with T = Upp::wchar]':
D:/Dev/0/1/libUpp/Core/Topt.h:223: instantiated from `void Upp::AssertMoveable(T*) [with T = Upp::wchar]'
D:/Dev/0/1/libUpp/Core/Vcont.h:89: instantiated from `Upp::Vector<T>::~Vector() [with T = Upp::wchar]'
D:/Dev/0/1/libUpp/Core/Vcont.h:88: instantiated from `Upp::Vector<T>::~Vector() [with T = Upp::Vector<Upp::wchar>]'
D:\Dev\0\1\libUpp\PdfDraw/PdfDraw.h:330: instantiated from here
D:/Dev/0/1/libUpp/Core/Topt.h:214: error: invalid type argument of `unary *'
According to NTL requirements, wchar should be moveable. But that Assert fails.
template <class T>
inline void AssertMoveablePtr(T, T) {}
template <class T>
inline void AssertMoveable0(T *t) { AssertMoveablePtr(&**t, *t); }
T is wchar. That would be: &**(wchar*). **(wchar*) doesn't make sense. How does that check if the type is moveable?
|
You cannot make a C++ automatic check here. Moveable types have to explicitly tagget by Moveable by deriving from Moveable<T> or by NTL_MOVEABLE macro. That overrides AssertMoveable and this way is not used.
What you see is used to make all pointers moveable. (Little bit confusing, but the only possible way).
Problem with wchar migth be caused by missing defines. Please, do what I asked - run UWord compilation with verbose mode active to see all defines...
Mirek
|
|
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11415 is a reply to message #11360] |
Wed, 12 September 2007 02:25 |
sergei
Messages: 94
Registered: September 2007
|
Member |
|
|
OK, I see that I've sounded a bit too ignorant and stubborn. Sorry for that. To clarify things:
1) I'm not afraid of TheIDE, I just don't like it. I just got myself comfortable with Code::Blocks, so I don't want to move to a new IDE to use a new library. I used it a bit, and found it less comfortable than Code::Blocks.
2) I want to build U++ without TheIDE not only for the reason that I don't want to use TheIDE. I want to ensure the library code is not tied to the development environment, and is pretty much standalone. In the hypotetical case of TheIDE ceasing to function, I want to still be able to build whatever I write with U++.
3) I've built UWord with TheIDE, with verbose. It just seemed that it included too few packages, so I guessed others also might be needed in other applications. Currently, apart from packages that are used in UWord, I added GLCtrl and GridCtrl (I hope none of these can cause trouble). I also added more plugins
Command line in TheIDE:
c++ -c -I"C:\upp\examples" -I"C:\upp\uppsrc" -I"C:\upp\mingw\include" -DflagGUI -DflagGCC -DflagDEBUG -DflagDEBUG_FULL -DflagBLITZ -DflagW
IN32 -DbmYEAR=2007 -DbmMONTH=9 -DbmDAY=12 -DbmHOUR=0 -DbmMINUTE=30 -DbmSECOND=10 -g2 -static -fexceptions -D_DEBUG -O0 -x c++ "C:\up
p\uppsrc\CtrlLib\ChWin32.cpp" -o "C:/upp/out/CtrlLib/MINGW.Debug_full.Gui\ChWin32.o"
I don't know what -D means (doesn't appear in c++ --help), but if these are defines, I need to define: flagGUI, flagGCC, flagDEBUG, flagDEBUG_FULL, flagBLITZ, flagWIN32. Should've done this last time (got overhauled with info due to verbose and missed these defines).
wchar problem is now gone (phew). Got some wrong stuff in Locale.cpp (I'm using dev2b from sourceforge, it might be outdated by now - there was and extra */ and missing :: to call Win32 functions). t.h is really weird. I've removed namespace from it, got back to the compiler error. Writing UPP::LngEntry__ solved the problem, but I still don't understand how INITBLOCK_ is defined there (t.h is included outside UPP namespace). Well, actually I don't understand how INITBLOCK works at all, it looks like some kind of lambda for C++, does it actually execute the code (register) upon program loading, without calling anything?
I'm getting closer to building U++. It took 43 minutes to get to the first error, which is in RichText (last package to be built). What bothers me is that the build time is so long, and that I get the same warnings over and over again. It's as if Core.h gets re-included for every CPP, and warnings from all its includes repeat (impossible since Core.h has include guards). I might later try to set Core.h to get precompiled and see if it helps.
The RichText error was in Para.cpp. It included an NText.h (non-existant file), and also used Paragraph (non-existant class). On second look, TheIDE used RichText in UWord, but that particular file wasn't used. I wonder how TheIDE knew it wasn't necessary, especially since Para.h is used. Removed the file, compilation continued.
#ifndef USE_MSDOS_MEMMGR /* make sure user got configuration right */
You forgot to define USE_MSDOS_MEMMGR in jconfig.h. /* deliberate syntax error */
#endif
That's a funny way to say something's wrong 
Defined USE_MSDOS_MEMMGR in jconfig.h, got an error in jmemansi.c:
METHODDEF(void)
read_backing_store (j_common_ptr cinfo, backing_store_ptr info,
void FAR * buffer_address,
long file_offset, long byte_count)
{
if (fseek(info->temp_file, file_offset, SEEK_SET))
ERREXIT(cinfo, JERR_TFILE_SEEK);
if (JFREAD(info->temp_file, buffer_address, byte_count)
!= (size_t) byte_count)
ERREXIT(cinfo, JERR_TFILE_READ);
}
Structure has no temp_file member.
OK, I made some progress, time to sleep 
Accumulating changes to the original sources package (half of it, actually):
In all icpps using INITBLOCK, replace it with INITBLOCK_(BLK_###) - unique ### for every INITBLOCK.
In t.h, replace LngEntry__ with UPP::LngEntry__
In Locale.cpp, add NAMESPACE_UPP and END_UPP_NAMESPACE, define LOG(x) (what is this?), remove extra */, add :: to some Win32 function calls.
And add main.cpp with :
#include "Core/Core.h"
#include "Core/Core_init.icpp"
#include "CtrlCore/CtrlCore.icpp"
#include "RichEdit/RichEdit.icpp"
#include "CtrlLib/CtrlLib.icpp"
#include "RichText/RichImage.icpp"
#include "PdfDraw/PdfReport.icpp"
#include "plugin/bmp/BmpReg.icpp"
#include "plugin/gif/gif.icpp"
#include "plugin/jpg/jpgreg.icpp"
#include "plugin/png/pngreg.icpp"
#include "plugin/tif/tifreg.icpp"
void LinkUppInit() {}
P.S. I've found: http://en.wikipedia.org/wiki/Single_Compilation_Unit
Pros: only 1 file to compile, probably faster static lib compiling, also icpp issue solution
Cons: INITBLOCK-s will have to be replaced with unique INITBLOCK_(X)-s, possibly other similar changes, every new CPP will have to be added to that file that is compiled (it could be auto-generated, though).
P.S.2 Thinking of it now, RichImage.icpp has 2 INITBLOCK-s, how can TheIDE compile these in one source file? It's redefined in Code::Blocks, unless I replace it with INITBLOCK_(X) with different X.
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11417 is a reply to message #11415] |
Wed, 12 September 2007 09:20 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| sergei wrote on Tue, 11 September 2007 20:25 |
I don't know what -D means (doesn't appear in c++ --help), but if these are defines, I need to define: flagGUI, flagGCC, flagDEBUG, flagDEBUG_FULL, flagBLITZ, flagWIN32. Should've done this last time (got overhauled with info due to verbose and missed these defines).
|
Yes, check...
| Quote: |
t.h is really weird. I've removed namespace from it, got back to the compiler error.
|
What is the error? (Important part is from where t.h was included).
| Quote: |
Writing UPP::LngEntry__ solved the problem, but I still don't understand how INITBLOCK_ is defined there (t.h is included outside UPP namespace). Well, actually I don't understand how INITBLOCK works at all, it looks like some kind of lambda for C++, does it actually execute the code (register) upon program loading, without calling anything?
|
It creates a special class and single global object of that class; uses constructor of the class to insert initialization code. It is pure macro hackery; the name of class and of object is created based on the line number.
| Quote: |
I'm getting closer to building U++. It took 43 minutes to get to the first error, which is in RichText (last package to be built). What bothers me is that the build time is so long, and that I get the same warnings over and over again. It's as if Core.h gets re-included for every CPP, and warnings from all its includes repeat (impossible since Core.h has include guards). I might later try to set Core.h to get precompiled and see if it helps.
|
Yes, it gets included all the time. Anyway, long build times is the thing that theide solves too (with theide, BLITZ and HYDRA - I can completely rebuild UWord, including U++ library, in 24s seconds with mingw and in 14s with MSC...)
| Quote: |
The RichText error was in Para.cpp. It included an NText.h (non-existant file), and also used Paragraph (non-existant class).
|
Once again, follow the suggestions. The list of files that really are part of project is displayed in theide and also listed in .upp files inside package directories (also there is the dependency). (OTOH, thanks, this looks like abandoned file that was forgot in the folder).
| Quote: |
#ifndef USE_MSDOS_MEMMGR /* make sure user got configuration right */
You forgot to define USE_MSDOS_MEMMGR in jconfig.h. /* deliberate syntax error */
#endif
That's a funny way to say something's wrong
Defined USE_MSDOS_MEMMGR in jconfig.h, got an error in jmemansi.c:
METHODDEF(void)
read_backing_store (j_common_ptr cinfo, backing_store_ptr info,
void FAR * buffer_address,
long file_offset, long byte_count)
{
if (fseek(info->temp_file, file_offset, SEEK_SET))
ERREXIT(cinfo, JERR_TFILE_SEEK);
if (JFREAD(info->temp_file, buffer_address, byte_count)
!= (size_t) byte_count)
ERREXIT(cinfo, JERR_TFILE_READ);
}
Structure has no temp_file member.
|
Well, these files are not from us, but this is jpeg library. Anyway, I think the problem might be the same as with RichText - redundant file compiled. Please check in theide or in .upp file whether this file is part of package. Same for Local.cpp.
(OTOH, this is really good, as we are now able to remove forgotten files .
| Quote: |
P.S. I've found: http://en.wikipedia.org/wiki/Single_Compilation_Unit
Pros: only 1 file to compile, probably faster static lib compiling, also icpp issue solution
Cons: INITBLOCK-s will have to be replaced with unique INITBLOCK_(X)-s, possibly other similar changes, every new CPP will have to be added to that file that is compiled (it could be auto-generated, though).
|
Ah, nice, somebody else noticed the basic principle of BLITZ too. Anyway, the difference is that BLITZ does all things automagically, solving the .icpp problem, creating the "SCU" and managing this so that frequently modified files are compiled separately.
| Quote: |
P.S.2 Thinking of it now, RichImage.icpp has 2 INITBLOCK-s, how can TheIDE compile these in one source file? It's redefined in Code::Blocks, unless I replace it with INITBLOCK_(X) with different X.
|
See above. They get different names within single file, which is OK as the global variable is static.
Mirek
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11426 is a reply to message #11360] |
Wed, 12 September 2007 12:31 |
sergei
Messages: 94
Registered: September 2007
|
Member |
|
|
I hoped moving away from MFC would result in getting away from all the macros, but I see they're alive and kicking...
How does it replace anything with line number? TheIDE feature? I've never seen this available in standard C++. If it's non-standard, why not replace all INITBLOCK with INITBLOCK_(X)-s? There are only about 30 of them.
I don't want to kill that 43-mins build effort, but IIRC since main.cpp compiled first:
#include "Core/Core.h"
#include "Core/Core_init.icpp"
...
t.h was included from Core_init.icpp:
#include "Core.h"
#define TFILE <Core/Core.t>
#include <Core/t.h>
The error with the unmodified file was that LngEntry was undefined (quite understandable, since Core_init.icpp doesn't have NAMESPACE_UPP). Less understandable is that the INITBLOCK actually ceases to function if I add NAMESPACE_UPP to t.h.
BLITZ is pretty impressive if it can understand which CPPs are unused (especially for CPPs sucha s Locale.cpp, that don't have H-s). But that's what I like about static libs - everything has to be compiled, so you can be sure you have no code that is simply unreferenced.
I don't yet understand why Core.h gets reincluded all the time (don't include guards prevent this?). But I think a rather simple batch could be used to create main.cpp with all CPPs/icpps included, and compile just it. BTW, does the whole static lib always get linked, or only the referenced part of it (if only part may get linked, then single compilation unit isn't a good solution)?
Here are unreferenced files from jpg:
ansi2knr.c
cjpeg.c
ckconfig.c
djpeg.c
example.c
jmemdos.c
jmemmac.c
jmemname.c
jmemnobs.c
jpegtran.c
rdjpgcom.c
wrjpgcom.c
Here are unreferenced files from tif:
fax3sm_winnt.c
mkg3states.c
mkspans.c
mkversion.c
tif_acorn.c
tif_apple.c
tif_atari.c
tif_msdos.c
tif_stream.cxx
tif_unix.c
tif_vms.c
tif_win3.c
tif_win32.c
I removed zim plugin since it didn't want to compile and I didn't see an example using it.
Now I have a 408MB static debug library 
What's the largest debug exe ever built with U++? Does it even come close?
I am somewhat worried about stuff I removed, some of it might be used for other platforms (I don't have unix/linux/macosx).
Now I can try single compilation unit, release, precompiled headers.
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11427 is a reply to message #11426] |
Wed, 12 September 2007 14:25 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| sergei wrote on Wed, 12 September 2007 06:31 |
I hoped moving away from MFC would result in getting away from all the macros, but I see they're alive and kicking...
How does it replace anything with line number? TheIDE feature? I've never seen this available in standard C++.
|
__LINE__ as a pseudomacro defined by C and C++ standard. It returns the current line number. With a little bit of macro hackery magic, you can use this to build identifier with line number in it.
| Quote: |
If it's non-standard, why not replace all INITBLOCK with INITBLOCK_(X)-s? There are only about 30 of them.
|
Not using macros is better than using them. Using macros for things that repeat and cannot be done without macros is better than repeating...
| Quote: |
t.h was included from Core_init.icpp:
#include "Core.h"
#define TFILE <Core/Core.t>
#include <Core/t.h>
The error with the unmodified file was that LngEntry was undefined (quite understandable, since Core_init.icpp doesn't have NAMESPACE_UPP). Less understandable is that the INITBLOCK actually ceases to function if I add NAMESPACE_UPP to t.h.
|
Ha! So the same issue again, forgotten file. Thank explains it.
| Quote: |
BLITZ is pretty impressive if it can understand which CPPs are unused (especially for CPPs sucha s Locale.cpp, that don't have H-s). But that's what I like about static libs - everything has to be compiled, so you can be sure you have no code that is simply unreferenced.
|
Can you please carefully read again what I wrote about what files are to be compiled? Please...
| Quote: |
I don't yet understand why Core.h gets reincluded all the time (don't include guards prevent this?).
|
Yes, they do. That is why it can be included so many times.
| Quote: |
But I think a rather simple batch could be used to create main.cpp with all CPPs/icpps included, and compile just it. BTW, does the whole static lib always get linked, or only the referenced part of it (if only part may get linked, then single compilation unit isn't a good solution)?
|
Yes, that is why release mode does not use BLITZ SCU so that .libs are build from many .obj and unreferences .objs can be removed. That is also the solely reason for .icpp - these initialization blocks are not referenced from the rest of the code, that is why if they are put into .lib, linker simply excludes them and no initialization happens.. That is why theide build process does not put them into .lib, but links them directly as .obj -> that is the only difference.
| Quote: |
Now I have a 408MB static debug library
What's the largest debug exe ever built with U++? Does it even come close?
|
Optimized release mode about 10MB (that is really big app, about one million lines).
Debug mode (with debug info) theide has about 20-30MB with GCC.
| Quote: |
I am somewhat worried about stuff I removed, some of it might be used for other platforms (I don't have unix/linux/macosx).
|
So? Your task was to build libs for Win32, so what is the problem?
Thank you for trying. The fact is, for me and other core U++ developers, lib form of U++ is quite redundant, but I understand that it can be quite atractive for many people. Any effort here is highly welcome...
Mirek
|
|
|
|
|
|
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11439 is a reply to message #11417] |
Wed, 12 September 2007 18:20 |
Novo
Messages: 1358
Registered: December 2006
|
Ultimate Contributor |
|
|
| luzr wrote on Wed, 12 September 2007 03:20 |
Yes, it gets included all the time. Anyway, long build times is the thing that theide solves too (with theide, BLITZ and HYDRA - I can completely rebuild UWord, including U++ library, in 24s seconds with mingw and in 14s with MSC...)
|
This is really cool feature of TheIDE. Is it possible to use the build system of TheIDE as a standalone application? I have two reasons to ask for this.
1) I cannot build TheIDE at work because we use somewhat outdated distributives. (Probably I haven't tried too hard.)
2) I'd like to use it with other IDE (VIM in my case).
Thanks.
Regards,
Novo
|
|
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11442 is a reply to message #11439] |
Wed, 12 September 2007 18:47 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| Novo wrote on Wed, 12 September 2007 12:20 |
| luzr wrote on Wed, 12 September 2007 03:20 |
Yes, it gets included all the time. Anyway, long build times is the thing that theide solves too (with theide, BLITZ and HYDRA - I can completely rebuild UWord, including U++ library, in 24s seconds with mingw and in 14s with MSC...)
|
This is really cool feature of TheIDE. Is it possible to use the build system of TheIDE as a standalone application? I have two reasons to ask for this.
1) I cannot build TheIDE at work because we use somewhat outdated distributives. (Probably I haven't tried too hard.)
2) I'd like to use it with other IDE (VIM in my case).
Thanks.
|
You can use "umk" - as long as you can stand with packages (but in reality, system of packages is a perfect match for BLITZ, as it creates natural groups of files).
Mirek
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11443 is a reply to message #11442] |
Wed, 12 September 2007 20:04 |
Novo
Messages: 1358
Registered: December 2006
|
Ultimate Contributor |
|
|
| luzr wrote on Wed, 12 September 2007 12:47 |
| Novo wrote on Wed, 12 September 2007 12:20 |
| luzr wrote on Wed, 12 September 2007 03:20 |
Yes, it gets included all the time. Anyway, long build times is the thing that theide solves too (with theide, BLITZ and HYDRA - I can completely rebuild UWord, including U++ library, in 24s seconds with mingw and in 14s with MSC...)
|
This is really cool feature of TheIDE. Is it possible to use the build system of TheIDE as a standalone application? I have two reasons to ask for this.
1) I cannot build TheIDE at work because we use somewhat outdated distributives. (Probably I haven't tried too hard.)
2) I'd like to use it with other IDE (VIM in my case).
Thanks.
|
You can use "umk" - as long as you can stand with packages (but in reality, system of packages is a perfect match for BLITZ, as it creates natural groups of files).
Mirek
|
umk will run theide.exe (is it called theide.exe on Unix?). That is not exactly what I want, because I cannot build TheIDE on Linux. I want a pure command line utility. UPP seems to be something more than just a GUI library .
Is there a dedicated build system API, which I can use to develop such a tool without reimplementing everything by myself? That would save a lot of time.
I'm sorry, I probably shouldn't ask such stupid questions.
Thanks.
Regards,
Novo
|
|
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11449 is a reply to message #11360] |
Thu, 13 September 2007 01:19 |
sergei
Messages: 94
Registered: September 2007
|
Member |
|
|
I've encountered 2 problems:
1) GUI EXEs simply refuse to run. When I try to debug them, they "stall" before reaching WinMain. Executed, they just disappear (that is, launch and terminate immediately). Console programs work fine. I'd be glad to hear any ideas about what could go wrong. Just in case, here's how I reference my static lib (I made UppGUI.h):
#ifndef UPP_H_INCLUDED
#define UPP_H_INCLUDED
#define flagGUI
#define flagGCC
#define flagBLITZ
#define flagWIN32
#if defined(DEBUG) || defined(_DEBUG)
#define flagDEBUG
#define flagDEBUG_FULL
#endif
#include <CtrlLib/CtrlLib.h>
using namespace Upp;
void LinkUppInit();
#define APP_MAIN INITBLOCK { LinkUppInit(); } GUI_APP_MAIN
#endif // UPP_H_INCLUDED
2) The icpps solution Mirek suggested (dummy function for each) is indeed better than mine (main.cpp for all). It became obvious when removing LinkUppInit halved the EXE size (to 1.5MB) UWord is 2.3MB with GCC, so without LinkUppInit my static lib approach doesn't seem to incur any size penalty. Yet a question arises - how a regular build environment should decide which icpp should be linked and which shouldn't? For instance, RichText is included in CtrlLib.h, but might not be referenced in the program and thus thrown out by the linker. But if I call its link, it definitely won't be thrown out, even if unused.
A solution could be to let the users decide which links to call. But that's not nice.
A better solution (IMHO) is to convert these icpps to regular CPPs, and call the dummy function in the most important function of the package. This might not be simple, but there is logic basis to this idea - functions take care of their requirements. E.g. for PdfDraw, it would make sense to put that call in GetDrawingToPdfFn function (in Draw/DrawUtil), since it's there that the initialization of the static variable is needed. There should be no problem to put several dummy calls in places necessary.
|
|
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11451 is a reply to message #11449] |
Thu, 13 September 2007 05:45 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| sergei wrote on Wed, 12 September 2007 19:19 |
A solution could be to let the users decide which links to call. But that's not nice.
A better solution (IMHO) is to convert these icpps to regular CPPs, and call the dummy function in the most important function of the package. This might not be simple, but there is logic basis to this idea - functions take care of their requirements. E.g. for PdfDraw, it would make sense to put that call in GetDrawingToPdfFn function (in Draw/DrawUtil), since it's there that the initialization of the static variable is needed. There should be no problem to put several dummy calls in places necessary.
|
Heh, this sounds like reproducing the route that ultimately has led to .icpp.
Sure, first we have placed just this - calls to dummy functions at strategic places.
Anyway, this is not possible when the mere presence of package in project should mean something.
For example, .icpp in PdfDraw: If you have PdfDraw in project, Report viewer has "Export to PDF..." button. If not, no button.
The same is true for image plugins. You just add image format plugin package you need in your application.
You do not have to do anything else than adding the package. Thanks to .icpp...
Mirek
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11455 is a reply to message #11360] |
Thu, 13 September 2007 15:43 |
sergei
Messages: 94
Registered: September 2007
|
Member |
|
|
I'm starting to see the big picture. There are 2 options:
1) Compiler decides what goes in and what doesn't.
2) User decides what goes in and what doesn't.
I wanted to go for option 1 - that way, if user uses PDF, PDF goes in. I understand that U++ works according to option 2 - what's in, is used. That is actually easier to implement.
My current idea goes like this:
1) Take the source, create a project (in any compiler/IDE) for a static library.
2) Add all files in all packages (according to .upp to exclude forgotten/unused files, and maybe exclude TheIDE-only packages).
3) Remove .icpps from the project (they will not be compiled).
4) Build debug/release/whatever libs.
5) Make a new project (that will use U++).
6) Include main headers of packages used, and icpps of packages used (only once, into one of the project's cpps).
7) Build the project - linker will throw out unused packages, and initialize used packages since the icpps were included.
I'd like to automate this process. I'll try to make a program to scan folder structure, parse .upps, create static lib project (e.g. include only used files), and create package headers.
By package headers, I mean it will be a header that handles icpps and dependencies inside. Example (upppkg/CtrlLib.h):
#ifndef UPPPKG_CTRLLIB_H
#define UPPPKG_CTRLLIB_H
// Uses
#include <upppkg/CtrlCore.h>
#include <upppkg/RichText.h>
// Uses (platform)
#ifdef flagLINUX
#include <upppkg/PdfDraw.h>
#endif
#ifdef flagFREEBSD
#include <upppkg/PdfDraw.h>
#endif
#ifdef flagOSX11
#include <upppkg/PdfDraw.h>
#endif
// Header
#include <CtrlLib/CtrlLib.h>
// ICPP
#include <CtrlLib/CtrlLib.icpp>
#endif
Linking to libUpp and including this file should basically provide a similar environment as TheIDE provides, when you write #include <CtrlLib/CtrlLib.h> and add this package.
What do you think of this idea? It would take a second to generate headers from U++ source, another ~20 mins to build the library, and U++ is ready to use.
Questions:
1) Is the first header in file section of .upp always the most important one of that package? If not, how can the main header be determined?
2) I've found files with other extensions (not h/hpp/c/cpp/icpp) that maybe should be handled somehow - .dli, .iml, .in, .lay, .patch, .t, .upt, .usc, .vc. How should I take care of these?
3) Having a static lib + correct includes, there should be no problem using them in any project - exe/dll/lib, right? I've seen in another thread that there are problems with using U++ DLL in U++ EXE - wouldn't static linking each to U++ just work (OK, 1MB or so wasted, but still)?
P.S. I've tried to start making that parser, encountered 3 problems:
1) ToUnixName is implemented in Path.cpp but not defined in Path.h - can't use it.
2) I didn't find anything looking like this in the sources:
#ifdef PLATFORM_WIN32
const char cDirSep = '\\';
#else
const char cDirSep = '/';
#endif
Is there any reason for constantly using the chars '\\' and '/' and checking the OS?
3) I don't understand how unicode is implemented. There is String, AString, WString, but there is no TString, or whatever the name, like there is TCHAR that expands into char or wchar_t, depending on whether UNICODE/_UNICODE is defined. How do I define whether I'm in unicode or not? I mean, MessageBox will expand into MessageBoxA or MessageBoxW? And why path handling routines use char - can I handle unicode filenames with U++?
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11460 is a reply to message #11455] |
Thu, 13 September 2007 23:58 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| sergei wrote on Thu, 13 September 2007 09:43 |
1) Is the first header in file section of .upp always the most important one of that package? If not, how can the main header be determined?
|
Usually it is first, but it definitely does not need to be determined - it is determined by the name of #include from another package.
| Quote: |
2) I've found files with other extensions (not h/hpp/c/cpp/icpp) that maybe should be handled somehow - .dli, .iml, .in, .lay, .patch, .t, .upt, .usc, .vc. How should I take care of these?
|
Ignore them, they are #included (if necessary).
| Quote: |
3) Having a static lib + correct includes, there should be no problem using them in any project - exe/dll/lib, right? I've seen in another thread that there are problems with using U++ DLL in U++ EXE - wouldn't static linking each to U++ just work (OK, 1MB or so wasted, but still)?
|
Frankly, I am not sure what might go wrong in that case... I think in principle, this should really work.
| Quote: |
1) ToUnixName is implemented in Path.cpp but not defined in Path.h - can't use it.
|
WinPath, UnixPath, NativePath "rework" slashes to the required direction.
| Quote: |
3) I don't understand how unicode is implemented. There is String, AString, WString, but there is no TString, or whatever the name, like there is TCHAR that expands into char or wchar_t, depending on whether UNICODE/_UNICODE is defined. How do I define whether I'm in unicode or not?
|
This is sort of irrelevant. There is no UNICODE mode. All the time you have 8-bit and 16-bit String/WString.
Recommended approach is to use UTF-8 encoding. In that case, both strings can contain unicode and there is simple conversion between them. (You can however use one of 15 WIN/ISO encodings as 8-bit default.
| Quote: |
I mean, MessageBox will expand into MessageBoxA or MessageBoxW?
|
Always into MassageBoxA. However, in U++ you rather use Prompt, which can work with UTF8.
| Quote: |
And why path handling routines use char - can I handle unicode filenames with U++?
|
Unfortunately, there is drawback caused by fact that we still have to support win98, so we cannot use W variants  . In practive, this is really minor trouble, but nothing to be happy about it.
Anyway, when you are using only functions from U++, there is automatic conversion between U++ default encoding and 8-bit encoding of Windows.
Mirek
|
|
|
|
Goto Forum:
Current Time: Sun Apr 28 14:19:03 CEST 2024
Total time taken to generate the page: 0.04374 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
I run the exe and nothing happens (neither is visible in task manager). Exes are about 3MB in release, 17MB in debug. Full rebuild (debug+release) for a minimal GUI app (which doesn't work, but anyway) is 24 sec.
