|
|
Home » Developing U++ » U++ Developers corner » Small fixe for OPENBSD package organizer configuration
Small fixe for OPENBSD package organizer configuration [message #53698] |
Wed, 22 April 2020 10:47 |
|
amrein
Messages: 278 Registered: August 2008 Location: France
|
Experienced Member |
|
|
Here is a small fix to get near to release state for OPENBSD (patch attached).
What I wanted to do (user cases) :
1. [ DONE ] - Get correct dependencies for X11, GTK, rt and dl on OPENBSD => small fixes for package organizer configuration is attached
2. [ TODO ] - Get INC += /usr/local/include and LIBPATH += /usr/local/lib inside package organizer configuration (but how?)
My only solution right now for the user case 2 is to add /usr/local/include and /usr/local/lib in a specific .bm file and call umk with this modified build method.
Is there a way to add a library path (LIBPATH) and include patch (INC) in package organizer configuration for a specific flag? According to U++ source code, LIBPATH and INC are pkg-config and .bm file dependent only.
[Updated on: Wed, 22 April 2020 22:43] Report message to a moderator
|
|
|
|
|
|
Re: Small fixe for OPENBSD package organizer configuration [message #53715 is a reply to message #53713] |
Fri, 24 April 2020 08:04 |
|
mirek
Messages: 14039 Registered: November 2005
|
Ultimate Member |
|
|
There should be no absolute paths listed in .upp files, that is the role of build methods (to act as "interface" between the source tree and build machine).
Now well, if these are autogenerated, maybe we can make it less ugly to detect OPENBSD when autogenerating them and add /usr/local just in that case?
(it would be better to detect in runtime, just in case that because of some miracle umks32 works, can we do that? What is the 'uname' output on OpenBSD?)
[Updated on: Fri, 24 April 2020 08:07] Report message to a moderator
|
|
|
|
Re: Small fixe for OPENBSD package organizer configuration [message #53717 is a reply to message #53715] |
Fri, 24 April 2020 11:51 |
|
amrein
Messages: 278 Registered: August 2008 Location: France
|
Experienced Member |
|
|
mirek wrote on Fri, 24 April 2020 08:04There should be no absolute paths listed in .upp files, that is the role of build methods (to act as "interface" between the source tree and build machine).
Now well, if these are autogenerated, maybe we can make it less ugly to detect OPENBSD when autogenerating them and add /usr/local just in that case?
(it would be better to detect in runtime, just in case that because of some miracle umks32 works, can we do that? What is the 'uname' output on OpenBSD?)
For me, adding internal include and internal libpath inside Package Organizer is the best way to have control over this without having to add hidden code to check for the OS and add /usr/local/include and /usr/local/lib if it's OpenBSD or any other new OS requiring this trick.
It's not user .bm includes list nor user .bm libpath list. It's an internal umk/ide/Core include and libpath and need to be added only for some OS like for instance here, OpenBSD.
Don't we already have include withing Package Organize (without the "When" clause)? I mean, if it already exist, why should we fight against it?
[Updated on: Fri, 24 April 2020 11:52] Report message to a moderator
|
|
|
Re: Small fixe for OPENBSD package organizer configuration [message #53719 is a reply to message #53717] |
Fri, 24 April 2020 14:07 |
|
mirek
Messages: 14039 Registered: November 2005
|
Ultimate Member |
|
|
amrein wrote on Fri, 24 April 2020 11:51mirek wrote on Fri, 24 April 2020 08:04There should be no absolute paths listed in .upp files, that is the role of build methods (to act as "interface" between the source tree and build machine).
Now well, if these are autogenerated, maybe we can make it less ugly to detect OPENBSD when autogenerating them and add /usr/local just in that case?
(it would be better to detect in runtime, just in case that because of some miracle umks32 works, can we do that? What is the 'uname' output on OpenBSD?)
For me, adding internal include and internal libpath inside Package Organizer is the best way to have control over this without having to add hidden code to check for the OS and add /usr/local/include and /usr/local/lib if it's OpenBSD or any other new OS requiring this trick.
It's not user .bm includes list nor user .bm libpath list. It's an internal umk/ide/Core include and libpath and need to be added only for some OS like for instance here, OpenBSD.
Don't we already have include withing Package Organize (without the "When" clause)? I mean, if it already exist, why should we fight against it?
"need to be added only for some OS" is exactly the build method domain... This is the same as in Win32, where there is autodetection code for localizing C++ compiler folder and setting paths to it.
In either case, adding 4 lines of code to bm generator is much simpler than changing .upp structure, changing Package organizer GUI code and ide/Builders code....
Mirek
|
|
|
Re: Small fixe for OPENBSD package organizer configuration [message #53726 is a reply to message #53719] |
Fri, 24 April 2020 19:40 |
|
amrein
Messages: 278 Registered: August 2008 Location: France
|
Experienced Member |
|
|
I guess, if it's only 4 lines for OpenBSD, it shouldn't hurt.
edit: It will only work on OpenBSD and not elsewhere. I mean, I will still have to use a modified .bm file to create correct Makefiles for umk or theide for OpenBSD if I'm on another platform. If not, I won't get correct INC and LIBPATH inside the Makefile. It's not a big issue.
[Updated on: Fri, 24 April 2020 20:03] Report message to a moderator
|
|
|
Goto Forum:
Current Time: Fri Sep 20 11:11:39 CEST 2024
Total time taken to generate the page: 0.05663 seconds
|
|
|