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 » 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 Go to next message
amrein is currently offline  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. Sad
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 #53707 is a reply to message #53698] Wed, 22 April 2020 22:50 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
I share this patch because I don't have enough svn write permission do fix those files myself (access denied).
Re: Small fixe for OPENBSD package organizer configuration [message #53712 is a reply to message #53698] Thu, 23 April 2020 12:40 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
I think that actually adding /usr/local/[lib, include] to default (I mean, autogenerated) .bm files is the trivial solution to the problem.

Do you see any downside?

Mirek
Re: Small fixe for OPENBSD package organizer configuration [message #53713 is a reply to message #53712] Thu, 23 April 2020 20:43 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
No downside but it's ugly?

Better to:

- add another array in Package class:
Array<OptItem> library_path;

- add in PackageEditor::PackageEditor()
Add("Internal include path", actual.include);
Add("Internal library path", actual.library_path);

- Make actual.include like other options in Package Organizze (I mean, with rw access to 'When' textfield so it can be flag activated/distribution specific)

- Then use those Package variables to fill Makefiles and default .bm files if those flags are active

Embarassed ?

I didn't find where "Internal include" (package.include) is used in TheIDE, so I renamed it "Internal include path".

[Updated on: Thu, 23 April 2020 20:46]

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 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
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 #53716 is a reply to message #53715] Fri, 24 April 2020 09:05 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
mirek wrote on Fri, 24 April 2020 08:04

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?)


Now in trunk - in OpenBSD, bm autogeneration should add /usr/local....

Also, patches are commited too. Next nightly should work with OpenBSD (I wonder whether there will more than zero users for that Smile

Mirek

[Updated on: Fri, 24 April 2020 09:06]

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 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
mirek wrote on Fri, 24 April 2020 08:04
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?)


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 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
amrein wrote on Fri, 24 April 2020 11:51
mirek wrote on Fri, 24 April 2020 08:04
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?)


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 Go to previous message
amrein is currently offline  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

Previous Topic: Can you test this is in Win32?
Next Topic: Skylark - Render 2 tables -- [SOLVED]
Goto Forum:
  


Current Time: Fri Mar 29 10:34:07 CET 2024

Total time taken to generate the page: 0.02692 seconds