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++ Library support » U++ Library : Other (not classified elsewhere) » Building & using U++ without TheIDE
Re: Building & using U++ without TheIDE [message #12212 is a reply to message #12210] Thu, 18 October 2007 17:49 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
luzr wrote on Thu, 18 October 2007 14:44

Well, but BLITZ is at this stage well defined and integral part of U++. It is sort of stardard SCU approach for U++. Why should we support another SCU based build system?

BTW, would not it much easier to just reuse BLITZ for the task? AFAIK, you already have the code that takes uppsrc and generates SCU out of it. So what is the difference from using genuine BLITZ code which in fact does something similar and can even do the same (after a bit of fixing of the code)?

Mirek



Why not? I can't just reuse BLITZ, since my code doesn't generate a big CPP file. It generates headers, that through the use of #includes implement SCU in any given compiler. If I reused BLITZ, I'd have to regenerate uppsrc on every modification - which would require some custom build setup - for every IDE. In my SCU, only if there is a serious change to the filesystem - add/remove file/package headers have to be regenerated. The SCU part is performed by the compiler's preprocessor. But as I said, if ReplaceText is the problem I think I can get around that.

I'm trying to make it simpliest to get running - it should look just like a library that you include/link, not an intimidating framework requiring own build process.
Re: Building & using U++ without TheIDE [message #12242 is a reply to message #11360] Sun, 21 October 2007 02:54 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
Update: I manually modified 710dev1 tree with the accepted changes, plus I had to add my modified z and png plugins (they're referenced in CtrlLib). I updated pkggen, now it handles BLITZ_INDEX__ and so the INITBLOCKs work the way they should.

Regarding ReplaceText, this error now happens only in MSVC, not MinGW. That's because in MinGW, <windows.h> is included. There, ReplaceText is defined and both declaration and definition become ReplaceTextA. In MSVC however, <windows.h> is split into several definitions, and <commdlg.h> is only included in Win32.cpp, in CtrlLib. Thus, in my SCU, declaration is ReplaceText, because only headers have been processed, and definition is ReplaceTextA, since Win32.cpp already was included. This incompatibility should be easily fixed by moving the include out of Win32.cpp into CtrlLib.h or some header included by it. Or by using <windows.h> in MSVC too. Why neither of these happened in the first place (and include was placed in CPP)?


By the way, NetNode requires mpr.lib, and it isn't Unicodized though a .dli exists. Why is it part of Core (adding another dependency)?
Re: Building & using U++ without TheIDE [message #12251 is a reply to message #12242] Sun, 21 October 2007 22:26 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
sergei wrote on Sat, 20 October 2007 20:54


Regarding ReplaceText, this error now happens only in MSVC, not MinGW. That's because in MinGW, <windows.h> is included. There, ReplaceText is defined and both declaration and definition become ReplaceTextA. In MSVC however, <windows.h> is split into several definitions, and <commdlg.h> is only included in Win32.cpp, in CtrlLib. Thus, in my SCU, declaration is ReplaceText, because only headers have been processed, and definition is ReplaceTextA, since Win32.cpp already was included. This incompatibility should be easily fixed by moving the include out of Win32.cpp into CtrlLib.h or some header included by it. Or by using <windows.h> in MSVC too. Why neither of these happened in the first place (and include was placed in CPP)?



Actually, include was placed in CPP exactly to avoid problems you are having. There is no need to polute global namespace with more macros than necessarry. This way it polutes only CtrlLib, which is easily handled.

Quote:


By the way, NetNode requires mpr.lib, and it isn't Unicodized though a .dli exists. Why is it part of Core (adding another dependency)?



Well, you have to give some oportunity to develop things too Wink

Anyway, NetNode is being developed as we do not have any network browsing capabilities yet. It does not support UNICODE yet because

a) it was somewhat difficult to achieve
b) the chances that network nodes use UNICODE characters is not as high as for regular file names.

Mirek
Re: Building & using U++ without TheIDE [message #12256 is a reply to message #12251] Mon, 22 October 2007 01:39 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
Heh, that attempt backfired at me. Why doesn't it work that way in MinGW? This causes a certain compiler incompatibility. Unfortunately I don't know how to make the "good" MSVC version work. I could go back to previous include fashion that resembles BLITZ, but that would cause full rebuild on every build - not good. The problem is being unable to add CPPs to compiler on the fly.

...
Will you add my zlib (and png) plugins to the source tree? Without them, even the simpliest program won't work with my SCU, so the whole effort would be pointless to continue (Lib is good, but I'd like SCU too, especially since it almost works). If you will add them, I might add a scanner to pkggen to add necessary #undefs (though renaming ReplaceText would've been a lot easier Razz ).


Out of curiosity, am I right that ReplaceText wasn't supposed to become ReplaceTextA in RichEdit, and it just happened to work fine that way?


Regarding NetNode, it's good to see it developing, I just didn't like it being part of Core, requiring another library for even a trivial U++ app.


P.S. I can't properly preprocess RichEdit.h is MSVC, C:\upp710dev1\uppsrc\Core/Core.h(120) : fatal error C1189: #error : RTTI must be enabled !!! Find.cpp can be preprocessed. MinGW works too.
Re: Building & using U++ without TheIDE [message #12403 is a reply to message #12256] Sat, 27 October 2007 19:40 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
sergei wrote on Sun, 21 October 2007 19:39


Will you add my zlib (and png) plugins to the source tree?



I am hesitating a lot. I see no problem with updating those to the newer version; but I do not like fixing 3rd party code too much...

(I believe there are often even legal issues involved...)

BTW, what about suggesting your patches to original authors? That, IMO, would be the correct approach.

Quote:


Out of curiosity, am I right that ReplaceText wasn't supposed to become ReplaceTextA in RichEdit, and it just happened to work fine that way?



The truth is we do not care. If any identifier * is replaced by *A everywhere, it makes little difference.

Quote:


Regarding NetNode, it's good to see it developing, I just didn't like it being part of Core, requiring another library for even a trivial U++ app.



Well, the library is a standard part of Win32 API. U++ links to many Win32 .dlls, one more or less does not make any difference.

Mirek
Re: Building & using U++ without TheIDE [message #12409 is a reply to message #12403] Sun, 28 October 2007 02:04 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
There aren't any legal issues with BSD licences - you only have to mark them as modified (and open-source them too, but that will happen anyway).

I agree that as a general practice that would be bad, but I'm only talking about these few:

zlib - used in Core, thus simply has to be modified for SCU to work. Last update in 2005 - unlikely to change.
jpg - Often used. Last update in 1998 - won't change.
png, tif, bz2 - these are still rather active, so changes could be submitted to them. However, I doubt my modifications will be accepted - they are neither bugfixes nor functionality improvements, simply modifications for the plugin to make it work in another way.

I think that only z and png are used in all GUI apps. Thus they are a must. Rest aren't vital for trying out / working with U++. Modification to the (old) png version are simply adding casts. I'll try the latest version later. As I said, "big" ones like sqlite could be compiled in a separate lib.

In short - vital is zlib and png (hopefully new version will just work).


I still have no idea how to solve ReplaceText. That's really a technical challenge - how to make it work with headers and a single CPP file that has to include all of U++. Any help would be welcome.

Options:
1) The way I do it now - #include all packages headers into a single header (UppBase.h) included into program file. #include first all headers, then all sources of all packages into a single CPP file (UppBase.cpp). On MinGW that makes ReplaceText declared in UppBase.h become ReplaceTextA, and implementation in UppBase.cpp becomes ReplaceTextA too. On MSVC, ReplaceText in UppBase.h stays ReplaceText, yet implementation in UppBase.cpp becomes ReplaceTextA - error.
2) The way I did it before - #include everything into a single header (UppBase.h) - can be done per-package (pkg1hdr, pkg1src, pkg2hdr, pkg2src, ...). Then it will work on MinGW and MSVC (all will become ReplaceTextA). But then, every build, even a tiny change in program, will trigger full rebuild of U++ source (in first option that didn't happen since U++ source was in a never-changing UppBase.cpp).
3) Combine option 1 with option 2 - #include U++ per-package into UppBase.cpp, and only the headers into UppBase.h. ReplaceText will become ReplaceTextA in UppBase.cpp in both declaration and implementation, both MinGW and MSVC. However, in UppBase.h, ReplaceText will become ReplaceTextA only on MinGW, and will stay ReplaceText in MSVC - error.

Funny, but polluting the global namespace helps SCU Razz

Hmm, this could also be hacked by #defining ReplaceText ReplaceTextA in RichEdit.h... Is it better than changing the function name?

Re: Building & using U++ without TheIDE [message #12415 is a reply to message #12409] Mon, 29 October 2007 00:38 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
OK, I've tried the new PNG. It works, without a single change to the original code. I'm even stricter than you were - you changed #include "zlib.h" to #include <plugin/z/zlib.h>, I instead added a dummy zlib.h to plugin dir that points to z plugin Very Happy

Added these defines:

#define PNG_NO_MMX_CODE
#define PNG_USE_GLOBAL_ARRAYS

Didn't compile otherwise, and AFAIK MMX is disabled in currently used PNG too. I didn't really test the code, but since it's original unmodified and it compiles, it should work.


So, ReplaceText and zlib are the only showstoppers now. I added this to RichEdit.h:

#ifndef ReplaceText
#define ReplaceText ReplaceTextA
#endif

And used my zlib mod. Surprisingly, SCU EXE size is 2.0MB - same as Lib. I must've done something terribly wrong about the Lib, but I just can't figure out what. (OTOH, does anyone really care? 2MB for a GUI app isn't much, I've seen 20MB apps).


P.S. These few warnings in Core keep repeating many many times during Lib build, making it difficult to otice any other warnings, could they be fixed? (0 errors 0 warnings would be cool):

D:\Programming\Upp\Core/Topt.h(428) : warning C4311: 'type cast' : pointer truncation from 'const void *' to 'int'
D:\Programming\Upp\Core/Index.h(81) : warning C4244: 'argument' : conversion from 'intptr_t' to 'const int', possible loss of data
d:\programming\upp\core\Cbgen.h(805) : warning C4312: 'type cast' : conversion from 'int' to 'Upp::GateAction *' of greater size
D:\Programming\Upp\Core/Format.h(15) : warning C4311: 'type cast' : pointer truncation from 'const void *' to 'int'
D:\Programming\Upp\Core/Format.h(16) : warning C4311: 'type cast' : pointer truncation from 'const void *' to 'int'
  • Attachment: png.zip
    (Size: 335.35KB, Downloaded 331 times)
Re: Building & using U++ without TheIDE [message #12446 is a reply to message #12415] Thu, 01 November 2007 12:30 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
Any feedback? Will this PNG be accepted to source tree?
And what regarding ReplaceText, zlib, warnings?
Re: Building & using U++ without TheIDE [message #12468 is a reply to message #12446] Sun, 04 November 2007 12:34 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
sergei wrote on Thu, 01 November 2007 07:30

Any feedback? Will this PNG be accepted to source tree?



Apologies, too many things going on...

It is now accepted. Thanks, good job. (I only put zlib.h directly into /lib, as I believe #include "" would not be able to fetch it from plugin/png with GCC).

Quote:


And what regarding ReplaceText



I think I was clear enough. I do not think it is the fault of existing U++ code. I am not going to rename ReplaceText.

(Note that there are more possible name clashes in U++, all of them are resolved as long as the normal ("makefile") or U++ BLITZ is used.).

Quote:


, zlib, warnings?



Well, if only the exactly the same thing would be possible for zlib Smile

Warnings: I will look into that soon (remind me if I do not).

Mirek
Re: Building & using U++ without TheIDE [message #12474 is a reply to message #12446] Mon, 05 November 2007 09:06 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
sergei wrote on Thu, 01 November 2007 07:30

Any feedback? Will this PNG be accepted to source tree?



Update: Unfortunately, the updated PNG package does not compile *sometimes*.

Frankly, this is most puzzling, it worked on my desktop, but does not work on my notebook, with otherwise identical settings.

I have to investigate.... (meanwhile, I had to rollback it).

Mirek
Re: Building & using U++ without TheIDE [message #12481 is a reply to message #12474] Mon, 05 November 2007 11:10 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Update: So it seems nearly impossible to solve that without chnaging #include "zlib.h" in png.h.

If I put "fake" zlib.h as you did into plugin/png, it does not seem to work with mingw. With zlib.h in lib, it does not work with MSC...

So with this ugly thing, it is now back again...

Mirek

[Updated on: Mon, 05 November 2007 11:11]

Report message to a moderator

Re: Building & using U++ without TheIDE [message #12505 is a reply to message #12481] Tue, 06 November 2007 14:07 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
luzr wrote on Mon, 05 November 2007 12:10

Update: So it seems nearly impossible to solve that without changing #include "zlib.h" in png.h.

If I put "fake" zlib.h as you did into plugin/png, it does not seem to work with mingw. With zlib.h in lib, it does not work with MSC...

So with this ugly thing, it is now back again...

Mirek


How about 2 fake zlib.h? One in lib for MinGW, one in png for MSVC.

ReplaceText - OK. I can add the define in my SCU headers, that way uppsrc doesn't change.

zlib - there's absolutely no way to make K&R style fucntions work in C++. Though I might add another UppBase.c file, to compile C plugins there. That way it *might* work.

jpg - what about it, same as zlib? It's 1998, they aren't gonna change it Razz


Edit: thinking of it, how does BLITZ handle C plugins? They aren't BLITZ-approved, so each file is compiled separately as a C-file?

[Updated on: Tue, 06 November 2007 14:13]

Report message to a moderator

Re: Building & using U++ without TheIDE [message #12512 is a reply to message #12505] Tue, 06 November 2007 21:19 Go to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
sergei wrote on Tue, 06 November 2007 08:07

luzr wrote on Mon, 05 November 2007 12:10

Update: So it seems nearly impossible to solve that without changing #include "zlib.h" in png.h.

If I put "fake" zlib.h as you did into plugin/png, it does not seem to work with mingw. With zlib.h in lib, it does not work with MSC...

So with this ugly thing, it is now back again...

Mirek


How about 2 fake zlib.h? One in lib for MinGW, one in png for MSVC.

ReplaceText - OK. I can add the define in my SCU headers, that way uppsrc doesn't change.

zlib - there's absolutely no way to make K&R style fucntions work in C++. Though I might add another UppBase.c file, to compile C plugins there. That way it *might* work.

jpg - what about it, same as zlib? It's 1998, they aren't gonna change it Razz


Edit: thinking of it, how does BLITZ handle C plugins? They aren't BLITZ-approved, so each file is compiled separately as a C-file?



.c are excluded from BLITZ.

Mirek
Previous Topic: *.tpp files in SVN
Next Topic: console + WIN-GDI
Goto Forum:
  


Current Time: Thu Mar 28 20:27:05 CET 2024

Total time taken to generate the page: 0.01626 seconds