LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 10-09-2016, 02:21 PM   #1
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,277

Rep: Reputation: Disabled
Testers wanted - pkgconf, replacement for pkg-config


I have been considering if pkgconf could be a good replacement for pkg-config in slackware for reasons described upstream.

https://github.com/pkgconf/pkgconf/wiki/Roadmap

After some troubleshooting it seems to be working well as a drop-in replacement for pkg-config, but I am not able of thoroughly testing it by building many different packages. If anyone would like to help test it, that would be very much appreciated!

To use it just uninstall pkg-config, build & install pkgconf, and then get a new user session to have updated environment variables. Reversing the process can easily undo it. If there are any build issues encountered with pkgfconf make sure they don't occur with pkg-config before reporting, the opposite would be interesting to know too.

The build script can be found here.

https://notabug.org/orbea/Slackbuild...opment/pkgconf

And to clone the repo with it use:

git clone https://notabug.org/orbea/Slackbuilds

Here is the pkgconf source:

https://distfiles.dereferenced.org/p...f-1.0.1.tar.xz
md5sum - 336a3253ab31f7c26fc3d9d35c9844eb
 
Old 10-10-2016, 12:55 AM   #2
a4z
Senior Member
 
Registered: Feb 2009
Posts: 1,683

Rep: Reputation: 706Reputation: 706Reputation: 706Reputation: 706Reputation: 706Reputation: 706Reputation: 706
may I share some thoughts with you?
well this is a theoretical question, I will do it anyway

this:
Quote:
Originally Posted by orbea View Post
To use it just uninstall pkg-config, build & install pkgconf, and then get a new user session to have updated environment variables. Reversing the process can easily undo it. If there are any build issues encountered with pkgfconf make sure they don't occur with pkg-config before reporting, the opposite would be interesting to know too.
is not hte best way to test software. you have to provide an testing environment. put it into somewhere/bin, add this to begin of $PATH, add this and thata variable..., switch to this and back should be easy.


personal tip:
Never ever come with a managed c++ example. if you want this stay in the MS world, it is made for there and will stay there fore ever.
Stay with the standard.

Not quite in the standard (C++17) yet, but available on clang and MSVC (2015) as preview.
http://clang.llvm.org/docs/Modules.html
So this is the future.
If this might have an impact on the way we use C++ libraries, I don't know but I think so, will see.

Your example with build in compiler switch might be not the best.
I can change between different versions of libraries/include files via environment variables,
and I, and a lot of others, never ever use pkg-config , but cmake find library.
this has to work together with the environment I set up. Hardcoded paths in pkg confic can there more be a problem.

for the rest I do not see what current problem this should solve, can you please explain?
 
Old 10-10-2016, 01:49 PM   #3
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,277

Original Poster
Rep: Reputation: Disabled
This is to test replacing pkg-config entirely, to do that I need to overwrite some files from the pkg-config package, so its best to just remove it. The change is very easy to reverse.

I'm not sure what point you are trying to mke with C++17 and MSVC?

Adding the pkg-config directories with a configure flag seems to work well including multilib systems and is exactly how both debian and freebsd are doing it. If there is a problem with the implementation I would much prefer to see real examples and not some hypothetical scenario.
 
Old 10-10-2016, 08:18 PM   #4
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,277

Original Poster
Rep: Reputation: Disabled
I fixed an issue in my implementation that caused building spacefm to fail on multilib systems by correctly setting with-system-libdir. In Slackware it apparently should be /lib${LIBDIRSUFFIX} rather than defaulting to LIBDIR (/usr//lib${LIBDIRSUFFIX}).

https://notabug.org/orbea/Slackbuild...f19111333913c9
 
Old 10-11-2016, 12:14 AM   #5
a4z
Senior Member
 
Registered: Feb 2009
Posts: 1,683

Rep: Reputation: 706Reputation: 706Reputation: 706Reputation: 706Reputation: 706Reputation: 706Reputation: 706
Quote:
Originally Posted by orbea View Post
This is to test replacing pkg-config entirely, to do that I need to overwrite some files from the pkg-config package, so its best to just remove it. The change is very easy to reverse.

I'm not sure what point you are trying to mke with C++17 and MSVC?

Adding the pkg-config directories with a configure flag seems to work well including multilib systems and is exactly how both debian and freebsd are doing it. If there is a problem with the implementation I would much prefer to see real examples and not some hypothetical scenario.
the only available documentation I have seen is the roadmap, and there is seems that you would like to have this as an option for gcc.
the roadmap itself shows an example from managed C++, a code that not even theoretical runs on something beside the MS dotNet world, what's the point with this? but exactly this will be done in future with modules, on all platforms. If you do not even know this, than why the managed C++ code example on the homepage?
sorry for trying to help and giving you feedback and tell you something you did not know and from real work scenarios, will not happen again. But good luck with your project.
 
Old 10-11-2016, 12:08 PM   #6
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,277

Original Poster
Rep: Reputation: Disabled
The thing that initially made me interested was the reduced dependency on glib which pkg-config has, other than that is was mostly curiosity to see if it was better or worse. So far excluding my own mistakes in implementation it has been just as reliable and the responsive irc channel is encouraging.

The c++ code example on the roadmap is for gtk+3, hardly microsoft oriented. The feedback is appreciated though, but you do have to understand that hypothetical scenarios is not going help that much with testing pkgconf as an alternative to pkg-config.

Last edited by orbea; 10-11-2016 at 12:10 PM.
 
Old 05-14-2018, 01:27 PM   #7
a4z
Senior Member
 
Registered: Feb 2009
Posts: 1,683

Rep: Reputation: 706Reputation: 706Reputation: 706Reputation: 706Reputation: 706Reputation: 706Reputation: 706
any progress or news with this project?

I re-detected it recently, and while the roadmap is still not the best source of information for this project, and some of the goals are less important to me (compiler switch example)
this is quite interesting and has appealing parts:
http://pkgconf.org/features.html
 
Old 05-14-2018, 02:46 PM   #8
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,277

Original Poster
Rep: Reputation: Disabled
Pkgconf has been working here without any issues for a while now and the project seems fairly complete as far as Linux is concerned. I suppose cross-compile support may be even easier in the future when this issue is resolved. Its also relied upon a lot in projects like Fedora and Alpine so its well supported upstream.

Edit: Also its available at SBo now if anyone wants to try it.

http://slackbuilds.org/repository/14...pment/pkgconf/

Last edited by orbea; 05-14-2018 at 04:34 PM.
 
2 members found this post helpful.
Old 05-15-2018, 12:59 AM   #9
a4z
Senior Member
 
Registered: Feb 2009
Posts: 1,683

Rep: Reputation: 706Reputation: 706Reputation: 706Reputation: 706Reputation: 706Reputation: 706Reputation: 706
thanks for info!
seems to be save to give it a trial
 
Old 05-15-2018, 03:45 PM   #10
the3dfxdude
Member
 
Registered: May 2007
Posts: 561

Rep: Reputation: 236Reputation: 236Reputation: 236
I read the info on the project. It looks like it is an improvement over the existing .pc management. Fine. But I read the roadmap the devs put out, and none of these new features they are putting on the roadmap are actually anything I would want to integrate with in a software project. In fact, I don't want it, because it will likely cause more problems in the long run. This seems like they are being motivated by their customary practices on maintaining their distro rather than solving any developer's or upstream's need. So I'm afraid this is another project with the potential of entangling scope creep.
 
1 members found this post helpful.
Old 05-15-2018, 03:51 PM   #11
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,277

Original Poster
Rep: Reputation: Disabled
What scope creep? What developer and upstream needs are they not meeting?
 
Old 05-15-2018, 08:51 PM   #12
the3dfxdude
Member
 
Registered: May 2007
Posts: 561

Rep: Reputation: 236Reputation: 236Reputation: 236
Quote:
Originally Posted by orbea View Post
What scope creep? What developer and upstream needs are they not meeting?
It seems you misunderstood. As a pkg-config replacement, it seems they have met the objective. The scope creep begins on line 1 of the roadmap. The theme of their project is in this:
"So, essentially, what pkgconf is about is making our toolchain not suck, so we can have code that is more direct and to the point."

This is what they are replacing:
"pkg-config - Return metainformation about installed libraries"

So now we have a tool that was supposed to be about meta data that wants to insert itself into the toolchain and distro build process.
 
Old 05-15-2018, 10:59 PM   #13
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,277

Original Poster
Rep: Reputation: Disabled
Uhhh, what are you talking about? The legacy freedesktop.org pkg-config is already part of the toolchain and distro build process...
 
Old 05-16-2018, 01:00 AM   #14
a4z
Senior Member
 
Registered: Feb 2009
Posts: 1,683

Rep: Reputation: 706Reputation: 706Reputation: 706Reputation: 706Reputation: 706Reputation: 706Reputation: 706
the roadmap is a horrible document and should be rewritten, replaced, or deleted since it causes more confusion than clarity

the example more than just unlucky
and this '-framework' switch is nonsense, clearly
and we can already add to the command line `pkg-config --libs whateber`, which has the same effect.
this worked since ever and was also used as such.

however, there are reasons why revisiting pkg-config is a good idea, and improvement of speed and functionality are welcome, and it's also a good idea to put common functionality in a lib and provide an API
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[TESTERS WANTED] Upcoming slint-next installers Didier Spaier Slackware 17 03-30-2014 01:42 PM
[SOLVED] [TESTERS WANTED] Slint installers for Slackware 14.1 => LAST CALL Didier Spaier Slackware 11 11-22-2013 06:22 AM
70+ bug-fixes fro WindowMaker [testers wanted] gnashley Slackware 7 12-12-2009 08:38 AM
VirtualBox USB config test script; testers wanted catkin Linux - Virtualization and Cloud 42 10-23-2009 05:22 AM
Beta testers wanted for new distro (IBLS) ico2 Linux - Distributions 4 12-31-2005 07:18 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 09:05 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration