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 » Community » U++ community news and announcements » Getting ready 2/2015
Re: Getting ready 2/2015 [message #45170 is a reply to message #45167] Mon, 21 September 2015 19:29 Go to previous messageGo to previous message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
mirek wrote on Mon, 21 September 2015 17:23
timsky wrote on Mon, 21 September 2015 16:09
mirek wrote on Sun, 23 August 2015 11:18
I would like to make another release this year.

- mingw-w64 should come with it (to create better out-of-box experience)

Will you add MinGW to nightly builds too? Probably MinGW will significantly increase installer size. Right now it is great that U++ is so small and there is no need to wait for hours donloading it on slow connections.


Yes. I think mingw will add about 30MB to the download. I do not think it is a problem. But I can be persuaded to have "mingw-free" version...

Quote:

mirek wrote on Sun, 23 August 2015 11:18
- To simplify things, I am considering to remove some toolchains from Win32 auto-setup. Ideally, only VS2015 and SDK7 (which is the only SDK still coming with C++ compiler) should be supported. Detection method should also be changed to rather scan directories than read from registry.

Are you going to remove build methods for VS 2005 - 2013?
Please do not do that Shocked


I am not going to remove build methods, just automatic setup. Or, as things are developing, "portable setup" (it looks like there will be no install, theide will reconfigure upon starting).

OTOH, at some point in the future, C++11 will likely lure us to require C++11 compiler. At that point, U++ will not be able to compile with pre VS2015 MS compilers...

Mirek


Hi!

I'm all for portable installation, but I'm still dependent on MSC9: As I recall it, the Protect package from Max is dependent on that, and I'm dependent on Protect package... Is there any way to solve this issue? Looking forward, it would be great to have 64-bit support for Protect, but that's not possible with the current protection mechanism because of the compiler not supporting it.

Best regards,

Tom
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: PdfDraw and RichText->PDF export now support links
Next Topic: Official GITHub mirror
Goto Forum:
  


Current Time: Fri May 10 09:44:14 CEST 2024

Total time taken to generate the page: 0.01325 seconds