|
|
Home » Developing U++ » U++ Developers corner » Considering different approach to Win32 release
|
|
|
|
|
Re: Considering different approach to Win32 release [message #45287 is a reply to message #45284] |
Tue, 27 October 2015 12:48 |
Tom1
Messages: 1242 Registered: March 2007
|
Senior Contributor |
|
|
mirek wrote on Tue, 27 October 2015 12:00Tom1 wrote on Tue, 27 October 2015 09:20
No need for log, I found the cause: While in 'Build methods' Use BLITZ is not active by default for MSC9 or MSC10, in 'Output mode' dialog it is active by default for release mode. By switching it of in 'Output mode' cures the symptoms.
Best regards,
Tom
Well, but that is weird too, it should not be active... (unless you have activated it accidentally).
I reinstalled 9081 to be sure and in 'Output mode' dialog BLITZ is enabled for both debug and release modes out of the box. (Of course I had to create build methods for my MSC9 and MSC10 by using the Be verbose + Automatic setup, but that's really all.)
Best regards,
Tom
|
|
|
Re: Considering different approach to Win32 release [message #45288 is a reply to message #45282] |
Wed, 28 October 2015 07:57 |
|
mirek
Messages: 14039 Registered: November 2005
|
Ultimate Member |
|
|
cbpporter wrote on Tue, 27 October 2015 10:55Thank for the answers Mirek!
I tried with upp-win32-9087.7z.
After this step is done, maybe it is time to consider a more modern update mechanic? Big downloads and installs take away the old advantage of U++ of getting it up and running and updated using nightly builds.
Agreed, but perhaps not for this release. (It will take significant time to develop).
Quote:
I missed the VS2015 explanation. Does that mean that U++ now needs C++11? Our official compiler in 2010 .
No, not yet. That said, we would like like to move there eventually.
Anyway, it is true that with C++11, transfer semantics issues were changed, so some minimal changes to the code, backward compatible with C++98, are needed. It took about 5 minutes to fix theide, so no big deal.
Quote:
And what about MINGW not recognizing nullptr and other things? I think that the switch to MINGW will result in a lot of compatibility patches in user's code since MSC does take its fair share of liberties.
(fixed)
|
|
|
Re: Considering different approach to Win32 release [message #45289 is a reply to message #45287] |
Wed, 28 October 2015 07:58 |
|
mirek
Messages: 14039 Registered: November 2005
|
Ultimate Member |
|
|
Tom1 wrote on Tue, 27 October 2015 12:48mirek wrote on Tue, 27 October 2015 12:00Tom1 wrote on Tue, 27 October 2015 09:20
No need for log, I found the cause: While in 'Build methods' Use BLITZ is not active by default for MSC9 or MSC10, in 'Output mode' dialog it is active by default for release mode. By switching it of in 'Output mode' cures the symptoms.
Best regards,
Tom
Well, but that is weird too, it should not be active... (unless you have activated it accidentally).
I reinstalled 9081 to be sure and in 'Output mode' dialog BLITZ is enabled for both debug and release modes out of the box. (Of course I had to create build methods for my MSC9 and MSC10 by using the Be verbose + Automatic setup, but that's really all.)
Best regards,
Tom
Thanks, I believe I have figured it out (mingw had it active for release, and so it got there on first run).
Mirek
|
|
|
Re: Considering different approach to Win32 release [message #45290 is a reply to message #45287] |
Wed, 28 October 2015 08:06 |
Tom1
Messages: 1242 Registered: March 2007
|
Senior Contributor |
|
|
Hi,
Thanks Mirek. Now BLITZ is not active any more by default. After using the new menu for legacy compilers, all MSC9, MSC9x64, MSC10 and MSC10x64 variants work without BLITZ right from the start.
A side note for MINGW: When compiling the UWord example, both 32 and 64 bit variants produce executables that crash on start. (Running on Windows 8.1 Professional x64.) Don't know what's the actual problem but it seems to be cured after switching all optimizations off (flag O0).
Best regards,
Tom
|
|
|
|
|
|
|
|
|
Re: Considering different approach to Win32 release [message #45299 is a reply to message #45297] |
Thu, 29 October 2015 09:30 |
cbpporter
Messages: 1406 Registered: September 2007
|
Ultimate Contributor |
|
|
mirek wrote on Wed, 28 October 2015 20:20use
class Source : Moveable<Source>
That said, sometimes I am thinking that perhaps that "Moveable" thing is unnecessary... (It only serves to remind the programmer that there are rules about things put into Vector).
Thanks! So NTL_MOVEABLE no longer works under this setup?
It is weird tracking things down with all the difference s between compilers and version.
I have one final issue which I know how to solve:
Now, first of all, I shouldn't be using Pop, since I do not care about the value. I should be using Drop.
class Block: Moveable<Block> {
public:
VectorMap<String, Variable> Vars;
int Temps;
};
I get the error "use of deleted Block::Bock(const block&)" / "is implicitly deleted because the default definition would be ill-formatted".
Supposing I wanted to use Pop or any method with copy construction, which is the proper way to fix this to maximize compatibility with MSC2010 with its 1% C++11x compatibility, MSC15 and MINGW? Should I just write a copy constructor?
Anyway, main project now compiles under MINGW and all the changes to Core (only TimeStop precision issues) are now moved to my code base. I have no real interest in MINGW, but for the foreseeable future I shall be using MINGW just for testing purposes so I can report issues.
|
|
|
Re: Considering different approach to Win32 release [message #45300 is a reply to message #45297] |
Thu, 29 October 2015 09:42 |
Tom1
Messages: 1242 Registered: March 2007
|
Senior Contributor |
|
|
Hi Mirek,
I have now tested 9105 on Windows 8.1 Professional x64 with the following results:
1. From my point of view MSC9 and MSC10 both work perfectly OK now.
2. It still can't find the installed Visual studio 2015 community edition. Is this expected?
3. MINGW Debug compiles UWord correctly and the resulting executable works.
4. MINGW Size compiles UWord correctly and the resulting executable works.
5. MINGW Optimal compiles UWord but the resulting executable crashes. It requires dropping the speed optimization flag from O3 to O2 in order to make it work.
6. MINGW Speed compiles UWord but the resulting executable crashes. It requires dropping the speed optimization flag from O3 to O2 in order to make it work.
7. MINGWx64 Debug compiles UWord correctly and the resulting executable works.
8. MINGWx64 Size compiles UWord but the resulting executable crashes. (Switching from Os to e.g. O0 in size optimization flags fixes the executable.)
9. MINGWx64 Optimal compiles UWord but the resulting executable crashes. (Switching from Os to O0, O1, O2 or O3 in size optimization flags fixes the executable.)
10. MINGWx64 Speed compiles UWord correctly and the resulting executable works.
Best regards,
Tom
|
|
|
|
Re: Considering different approach to Win32 release [message #45304 is a reply to message #45300] |
Thu, 29 October 2015 13:22 |
|
mirek
Messages: 14039 Registered: November 2005
|
Ultimate Member |
|
|
Tom1 wrote on Thu, 29 October 2015 09:42Hi Mirek,
I have now tested 9105 on Windows 8.1 Professional x64 with the following results:
Thanks for testing! Definitely helpful.
Quote:
2. It still can't find the installed Visual studio 2015 community edition. Is this expected?
That is definitely unexpected and "wrong".
Well, instead of long and detailed request for investigation, could you please just look into ide/InstantSetup.cpp and put on line 180
vc = df.ScanForDir("/vc", "", "bin/link.exe;bin/cl.exe;bin/mspdb140.dll", "bin/1033");
bin = df.ScanForDir(x64 ? "bin/x64" : "bin/x86", "/windows kits/", "makecat.exe;accevent.exe", "");
inc = df.ScanForDir("", "/windows kits/", "um/adhoc.h", "um;ucrt;shared");
lib = df.ScanForDir("", "/windows kits/", "um/x86/kernel32.lib", "um;ucrt");
DUMP(vc); DUMP(bin); DUMP(inc); DUMP(lib); // <<==== THIS
if(vc.GetCount() * bin.GetCount() * inc.GetCount() * lib.GetCount()) {
bins.At(0) = vc + (x64 ? "/bin/amd64" : "/bin");
bins.At(1) = bin;
String& sslbin = bins.At(2);
and then run "Instant setup.." and look into .log?
(Explanation: Instead looking into registry (which proved error-prone with MSC12), theide now scans Program files directories and attempts to find appropriate directories.)
Quote:
3. MINGW Debug compiles UWord correctly and the resulting executable works.
4. MINGW Size compiles UWord correctly and the resulting executable works.
5. MINGW Optimal compiles UWord but the resulting executable crashes. It requires dropping the speed optimization flag from O3 to O2 in order to make it work.
6. MINGW Speed compiles UWord but the resulting executable crashes. It requires dropping the speed optimization flag from O3 to O2 in order to make it work.
7. MINGWx64 Debug compiles UWord correctly and the resulting executable works.
8. MINGWx64 Size compiles UWord but the resulting executable crashes. (Switching from Os to e.g. O0 in size optimization flags fixes the executable.)
9. MINGWx64 Optimal compiles UWord but the resulting executable crashes. (Switching from Os to O0, O1, O2 or O3 in size optimization flags fixes the executable.)
10. MINGWx64 Speed compiles UWord correctly and the resulting executable works.
Best regards,
Tom
Unfortunately, investigation revealed apparent bug in GCC optimizer (you can compile in release mode with full debug info and run in debug - bug in assembly is quite apparent).
I will try to downgrade gcc version. If that does not help (it should, in Linux it works fine), I will change -O levels...
Mirek
|
|
|
Re: Considering different approach to Win32 release [message #45305 is a reply to message #45303] |
Thu, 29 October 2015 13:43 |
cbpporter
Messages: 1406 Registered: September 2007
|
Ultimate Contributor |
|
|
mirek wrote on Thu, 29 October 2015 14:13cbpporter wrote on Thu, 29 October 2015 09:30mirek wrote on Wed, 28 October 2015 20:20use
class Source : Moveable<Source>
That said, sometimes I am thinking that perhaps that "Moveable" thing is unnecessary... (It only serves to remind the programmer that there are rules about things put into Vector).
Thanks! So NTL_MOVEABLE no longer works under this setup?
It is weird tracking things down with all the difference s between compilers and version.
I have one final issue which I know how to solve:
Now, first of all, I shouldn't be using Pop, since I do not care about the value. I should be using Drop.
class Block: Moveable<Block> {
public:
VectorMap<String, Variable> Vars;
int Temps;
};
I get the error "use of deleted Block::Bock(const block&)" / "is implicitly deleted because the default definition would be ill-formatted".
This another small difference. See http://www.ultimatepp.org/srcdoc$Core$pick_$en-us.html, Composition.
You need to add
rval_default(Block);
to the class.
Thank you!
I also needed to add a default constructor, but it works now.
|
|
|
Goto Forum:
Current Time: Fri Sep 20 23:01:27 CEST 2024
Total time taken to generate the page: 0.02940 seconds
|
|
|