|
|
Home » Community » U++ community news and announcements » theide/umk support for .lib/.a generation
|
Re: theide/umk support for .lib/.a generation [message #55576 is a reply to message #55571] |
Sun, 22 November 2020 20:24 |
|
Klugier
Messages: 1076 Registered: September 2012 Location: Poland, Kraków
|
Senior Contributor |
|
|
Hello Mirek,
That's great news!
Quote:
Now the hard part is to decide how to "parcel" the U++ into libraries. I am also afraid there will have to be like 12 versions of each library:
- USEMALLOC (not using U++ allocator)
- STDNEW (using standard new/delete, but U++ allocator where possible)
- with upp allocator
- Debug
- Release
- Linked with dynamic CRT
- Linked with static CRT
My point of view here is simple - the less variants we provide the better. In case of allocator I would choose only one option in context of .lib. Upp allocator should be exclusive for upp as a platform. So, I opt that we should use STDNEW only. Very good performance on library level, but user space is untouched. I think this is what most users want and do not create headache what option should be choose. In the very first version we could go with USEMALLOCK only.
In initial version we should only limit to RELEASE. In context of DEBUG works properly there is a need to distribute sources as well. In the first version the debugging of upp library should be only reserved to platform (TheIDE). I think initially there will not be many requests to add support for debug mode.
Providing CRT should be application responsibility. So, probably dynamic option is fine for us at least at the beginning. Mirek, do you see any objections difficulties here? The problem with static is that sometimes the CRT runtime is LGPL (Linux), so if we would like to go that path then we will need to make sure that we will do not link with libraries with that kind of license. I know that there is clang library that has BSD license. Anyway, this adds additional point of complexity, so initially I would focus only on dynamic version.
So, backing to math we could create only one variant instead of 12 and make whole solution simple This will also allow us to see how market will response and tune up in the future. KISS
---------------------------
In context of includes - will include works like this:
#include <Upp/CtrlLib/CtrlLib.h>
or do you plan to
#include <CtrlLib/CtrlLib.h>
I know that people might have objections for the second variant, so we should avoid it.
Klugier
U++ - one framework to rule them all.
[Updated on: Sun, 22 November 2020 20:25] Report message to a moderator
|
|
|
Re: theide/umk support for .lib/.a generation [message #55577 is a reply to message #55576] |
Sun, 22 November 2020 20:31 |
|
mirek
Messages: 13980 Registered: November 2005
|
Ultimate Member |
|
|
Klugier wrote on Sun, 22 November 2020 20:24Hello Mirek,
That's great news!
Quote:
Now the hard part is to decide how to "parcel" the U++ into libraries. I am also afraid there will have to be like 12 versions of each library:
- USEMALLOC (not using U++ allocator)
- STDNEW (using standard new/delete, but U++ allocator where possible)
- with upp allocator
- Debug
- Release
- Linked with dynamic CRT
- Linked with static CRT
My point of view here is simple - the less variants we provide the better. In case of allocator I would choose only one option in context of .lib. Upp allocator should be exclusive for upp as a platform. So, I opt that we should use STDNEW only. Very good performance on library level, but user space is untouched. I think this is what most users want and do not create headache what option should be choose. In the very first version we could go with USEMALLOCK only.
In initial version we should only limit to RELEASE. In context of DEBUG works properly there is a need to distribute sources as well. In the first version the debugging of upp library should be only reserved to platform (TheIDE). I think initially there will not be many requests to add support for debug mode.
Providing CRT should be application responsibility. So, probably dynamic option is fine for us at least at the beginning. Mirek, do you see any objections difficulties here? The problem with static is that sometimes the CRT runtime is LGPL (Linux), so if we would like to go that path then we will need to make sure that we will do not link with libraries with that kind of license. I know that there is clang library that has BSD license. Anyway, this adds additional point of complexity, so initially I would focus only on dynamic version.
So, backing to math we could create only one variant instead of 12 and make whole solution simple This will also allow us to see how market will response and tune up in the future. KISS
It is actually 24. I forgot about x86 vs x64. And you cannot really avoid debug/release and dynamic/static, because Visual Studio will disallow linking in incompatible modes.
Quote:
#include <CtrlLib/CtrlLib.h>
I know that people might have objections for the second variant, so we should avoid it.
KISS. Let us try the simple path first...
Mirek
|
|
|
Re: theide/umk support for .lib/.a generation [message #55578 is a reply to message #55571] |
Sun, 22 November 2020 21:50 |
Novo
Messages: 1358 Registered: December 2006
|
Ultimate Contributor |
|
|
mirek wrote on Sun, 22 November 2020 11:45
I hope somebody will step in here and start parceling U++ and creating the script or maybe just "CreatLibs" package in uppbox or something... In the end, maybe the only input information needed is which packages are to be converted with MAKE_LIB and which are not to be converted at all. Rest should be made with MAKE_MLIB....
I'm probably missing something, but isn't this stuff supposed to be a part of a Build Method?
You just need to auto-generate 24 different BM-files and everybody, who needs a library will just use an appropriate BM.
I'm doing this for sanitizers. This is just 6 more auto-generated BMs.
Regards,
Novo
|
|
|
Re: theide/umk support for .lib/.a generation [message #55579 is a reply to message #55577] |
Sun, 22 November 2020 21:56 |
|
Klugier
Messages: 1076 Registered: September 2012 Location: Poland, Kraków
|
Senior Contributor |
|
|
Hello Mirek,
Quote:It is actually 24. I forgot about x86 vs x64. And you cannot really avoid debug/release and dynamic/static, because Visual Studio will disallow linking in incompatible modes.
Make x86 pure optional. As far as I understand the libraries generation would be optional. As far as I understand on the instillation level we will give the user opportunity to generate standalone libraries depending on the needs. The question here is to specify reasonable defaults to shorten this process. In this case I agree with debug/release and static/dynamic CRT. So, in this case we should have 4 versions.
I see that on conan central there is similar matrix for libraries. So, for example for OpenSSL there is 24 variants for Windows and 52 for Linux.
Quote:KISS. Let us try the simple path first...
You are right, simpler approach is better. Many libraries do not use prefix for includes - we should be fine.
Klugier
U++ - one framework to rule them all.
[Updated on: Sun, 22 November 2020 21:59] Report message to a moderator
|
|
|
|
|
|
Re: theide/umk support for .lib/.a generation [message #55585 is a reply to message #55584] |
Mon, 23 November 2020 01:30 |
|
Klugier
Messages: 1076 Registered: September 2012 Location: Poland, Kraków
|
Senior Contributor |
|
|
Hello Mirek,
Let's target packages that do not have external dependencies. The only require dependency I see is OpenSSL for core. So in the first version, we shouldn't support MySQL, PostgreSQL etc. sqlite should be sufficient.
Of course, we should leave all IDE and main packages of uppsrc. IconDes, HexView, CppBase, Common (why this package is in uppsrc anyway?), DocTypes (legacy) are also do not need. Some plugins also like plugin/FT_fontsys, plugin/DroidFonts, plugin/zstd_legacy, plugin/astyle (this should be replaced with clang format) or plugin/ndisam.
Not sure about VirtualGUI/SDL2GL seems that this requires SDL. Geom and it's packages are absolute.
art/bluebar (seems absolute even TheIDE doesn't use it anymore)
Klugier
U++ - one framework to rule them all.
[Updated on: Mon, 23 November 2020 01:34] Report message to a moderator
|
|
|
|
|
|
Goto Forum:
Current Time: Tue May 21 19:17:05 CEST 2024
Total time taken to generate the page: 0.01899 seconds
|
|
|