|
|
Home » Community » U++ community news and announcements » Gearing up for 2022.1 release...
|
Re: Gearing up for 2022.1 release... [message #58255 is a reply to message #58249] |
Tue, 05 April 2022 21:00 |
Novo
Messages: 1358 Registered: December 2006
|
Ultimate Contributor |
|
|
Novo wrote on Tue, 05 April 2022 00:46
I do see a weird problem with Md5Stream. I'll check it tomorrow.
It turned out to be a weird problem with FindAllPaths + wine + unix-style path.
For examle:
FindAllPaths("/home/ssg/data/download", "*.pdf")
will return
v = Z:\home\ssg\dvlp\cpp\code\upp\out\MyApps\MINGWcpp17.Debug.Debug_Full.Gui.Shared.Win32\home\ssg\data\download\mysqluc2007-wikipedia-workbook.pdf
v = Z:\home\ssg\dvlp\cpp\code\upp\out\MyApps\MINGWcpp17.Debug.Debug_Full.Gui.Shared.Win32\home\ssg\data\download\recsplit.pdf
v = Z:\home\ssg\dvlp\cpp\code\upp\out\MyApps\MINGWcpp17.Debug.Debug_Full.Gui.Shared.Win32\home\ssg\data\download\StatisticsWithJuliaDRAFT.pdf
v = Z:\home\ssg\dvlp\cpp\code\upp\out\MyApps\MINGWcpp17.Debug.Debug_Full.Gui.Shared.Win32\home\ssg\data\download\UHHA Info Update 5-8-20.pdf
v = Z:\home\ssg\dvlp\cpp\code\upp\out\MyApps\MINGWcpp17.Debug.Debug_Full.Gui.Shared.Win32\home\ssg\data\download\web-prolog.pdf
v = Z:\home\ssg\dvlp\cpp\code\upp\out\MyApps\MINGWcpp17.Debug.Debug_Full.Gui.Shared.Win32\home\ssg\data\download\whole-book.pdf
This can be a problem with wine, Upp or both ...
Another thing. In case of Wine + Upp log-file is created in an app folder. SetConfigGroup is ignored. I guess this is done "by design".
Regards,
Novo
|
|
|
Re: Gearing up for 2022.1 release... [message #58256 is a reply to message #58255] |
Wed, 06 April 2022 09:07 |
Novo
Messages: 1358 Registered: December 2006
|
Ultimate Contributor |
|
|
It turned out that Windows has a command line package manager called "winget" now. (This, probably, was already discussed on this forum)
IMHO, it would be cool to have an Upp package for it.
Installing Upp via "winget install Upp" seems to be the easiest way to get it.
And "winget search upp" seems to be the easiest way to find it.
Regards,
Novo
|
|
|
|
Re: Gearing up for 2022.1 release... [message #58258 is a reply to message #58251] |
Wed, 06 April 2022 12:05 |
|
mirek
Messages: 13975 Registered: November 2005
|
Ultimate Member |
|
|
Klugier wrote on Tue, 05 April 2022 12:21mirek wrote on Sun, 03 April 2022 19:36Klugier wrote on Sun, 03 April 2022 15:43Hello Mirek,
I also proposed bumping C++ standard from c++14 to c++17. However, this could be done in the next release. There are a lot of risks here in context of compilation on various platforms.
Even if we do not have any features that particularly targets c++17 we should compile with that standard and our users should have access to it by default. Also, maybe this is a bug, but for MSVC we do not force any standard. It is always latest. I think it should change and we should target exactly the same standard as for GCC and CLANG.
Klugier
Yeeah, I was thinking about it a lot, problem is we have so far universal package for Posixes and we are not 100% sure c++17 compliant compiler is there. I think we would need to add detection code before adding -std=c++17 to options, which is sort of complicated and quirky.
Hello Mirek,
What about chaning approch? If it doesn't compile you could always back to older stable release of Upp. The old systems shouldn't hold us back and keep with old standard. We could make 2022.1 last official release with c++14 and the next one will be c++17.
The C++14 was introduced in 2017 in our code base. 3 years after official standard announcement. Right now we are 5 years after c++17. There is no consistency here.
Klugier
Uhm, now we are mixing 2 things I guess:
(1) C++ that is required by U++
(2) default C++ setting of build methods
So far I was speaking about (2). As for (1) I do not as of now see anything in C++17 that would make U++ codebase significantly better (cleaner, shorter, faster), so IMO it is not worth it to break U++ for old systems yet.
I could go with (2), but that would require detection system for posix install. IDK, maybe running "c++ -std=c++17" and detecting the error code would do the job?
Mirek
|
|
|
|
Re: Gearing up for 2022.1 release... [message #58261 is a reply to message #58260] |
Wed, 06 April 2022 19:21 |
Novo
Messages: 1358 Registered: December 2006
|
Ultimate Contributor |
|
|
Another issue.
Linking options from the "Output mode" dialog completely overwrite these options from a builder.
This is fine when you develop for only one platform. ("All static" for Windows and "Use shared libs" for POSIX)
But when you need to cross-compile this becomes a problem.
Suddenly your Windows apps start requiring dependencies ...
It took me quite a lot of time to realize that.
P.S. Interesting, what happens in case of umk ...
Regards,
Novo
[Updated on: Wed, 06 April 2022 19:49] Report message to a moderator
|
|
|
|
|
Re: Gearing up for 2022.1 release... [message #58265 is a reply to message #58262] |
Thu, 07 April 2022 12:16 |
Tom1
Messages: 1212 Registered: March 2007
|
Senior Contributor |
|
|
Hi,
Bundled clang in windows now seems up to version 14.0.0.
However, when linking my project with CLANG I get the following error:
Linking...
ld.lld: error: duplicate symbol: std::__throw_bad_alloc()
>>> defined at C:/upp-git/out/program/Core/CLANGx64.Blitz.Gui.Protect/heap.o
>>> defined at libc++.a(new.cpp.obj)
clang-14: error: linker command failed with exit code 1 (use -v to see invocation)
There were errors. (1:31.25)
Please note that this is not specific to CLANG-14 but also happened with previous CLANG version bundled.
Any idea where this comes from and suggestions how to proceed?
Best regards,
Tom
[Updated on: Thu, 07 April 2022 12:17] Report message to a moderator
|
|
|
|
|
Re: Gearing up for 2022.1 release... [message #58268 is a reply to message #58267] |
Thu, 07 April 2022 13:40 |
Tom1
Messages: 1212 Registered: March 2007
|
Senior Contributor |
|
|
Hi Mirek,
I thought, now that CLANG is at version 14, the issue would have been solved.
mstorsjo commented on Apr 23, 2021
This should have been fixed by the previous release (based on LLVM 11.0.0).
Best regards,
Tom
|
|
|
Re: Gearing up for 2022.1 release... [message #58269 is a reply to message #58268] |
Thu, 07 April 2022 15:07 |
Tom1
Messages: 1212 Registered: March 2007
|
Senior Contributor |
|
|
Hi Mirek,
I commented out the following line in heap.cpp:
void __attribute__((__noreturn__)) std::__throw_bad_alloc (void) { throw bad_alloc(); }
As a result the linker stopped complaining about it. Is this line required at all anymore?
(There are some external static libs I need that still prevent my app from running, but that's another story.)
Best regards,
Tom
|
|
|
|
Re: Gearing up for 2022.1 release... [message #58271 is a reply to message #58262] |
Thu, 07 April 2022 23:21 |
Novo
Messages: 1358 Registered: December 2006
|
Ultimate Contributor |
|
|
Novo wrote on Wed, 06 April 2022 13:34
And Upp should be tested against all versions of C++ because old code often doesn't compile with new versions of C++.
TheIDE cannot be compiled with C++20.
Clang + -std=c++20
/home/ssg/dvlp/cpp/code/upp/git/uppsrc/CtrlCore/CtrlPos.cpp:152:11: error: use of overloaded operator '!=' is ambiguous (with operand types 'Upp::Rect' (aka 'Rec
t_<int>') and 'Upp::Rect16' (aka 'Rect_<short>'))
if(view != f.view) {
~~~~ ^ ~~~~~~
/home/ssg/dvlp/cpp/code/upp/git/uppsrc/Core/Gtypes.h:337:9: note: candidate function
bool operator!=(const Rect_& b) const { return !operator==(b); }
^
/home/ssg/dvlp/cpp/code/upp/git/uppsrc/Core/Gtypes.h:336:9: note: candidate function
bool operator==(const Rect_& b) const;
^
/home/ssg/dvlp/cpp/code/upp/git/uppsrc/Core/Gtypes.h:336:9: note: candidate function (with reversed parameter order)
IMHO, this should be fixed.
Regards,
Novo
|
|
|
Re: Gearing up for 2022.1 release... [message #58273 is a reply to message #58270] |
Fri, 08 April 2022 09:43 |
Tom1
Messages: 1212 Registered: March 2007
|
Senior Contributor |
|
|
Hi Novo,
I like your idea of flexibility here. It is far easier to maintain projects across platforms if the latest uppsrc works nicely (i.e. is compatible) with all the standards from c++11 to c++20 -- or whatever the latest is. Anyway, there are always dependencies that cause all kinds of trouble with their requirements, so keeping uppsrc widely compatible is an excellent choice.
Best regards,
Tom
|
|
|
|
|
|
Goto Forum:
Current Time: Sat May 04 10:47:34 CEST 2024
Total time taken to generate the page: 0.02346 seconds
|
|
|