User forums > Using Code::Blocks

Info about lib finder

<< < (2/4) > >>

tiwag:

--- Quote from: MortenMacFly on October 10, 2006, 11:20:36 am ---..."Unfortunately" this works for me - so currently I don't know what happens in your case - could you give me a step-by-step explanation to reproduce?
With regards, Morten.

--- End quote ---

sorry, no i can't
now i do understand how it should work - i decide not to use it, thanks.

i don't see any effort with this plugin, i already know which libs i've installed.


what i do expect from a "lib finder" plugin, is to search all libs for exported symbols
for some unrefernced externals in case of a linker error and present me the name of
the libs, which are exporting these symbols.

brgds
tiwag

Max:

--- Quote from: tiwag on October 10, 2006, 11:40:15 am ---sorry, no i can't
now i do understand how it should work - i decide not to use it, thanks.

--- End quote ---

me too...  :D

I need to look for a lib only when I got unreferenced symbols because I forgot to add it. Every programmer knows which libs are installed in his programming environment... well may be not all programmers ... :D

Max

MortenMacFly:

--- Quote from: tiwag on October 10, 2006, 11:40:15 am ---what i do expect from a "lib finder" plugin, is to search all libs for exported symbols
for some unrefernced externals in case of a linker error and present me the name of
the libs, which are exporting these symbols.

--- End quote ---
Ok, got the point. So there is a misunderstanding. This plugin was focussing on new users to C::B to enable them to easily setup global variables - hoping to make this easier and let experts provide the knowledge about libs and their required configuration. Using gcv's in the end may lead to a more structured "C::B project design". Now there are the wizards which enable this, too but in a different ("hard-coded") way. So this is just another option.

What you expect is (IMHO) for a different developer level. I once did this using then "nm" tool and a perl script. nm was parsing all libs and piped interesing content in a text file. Then the perl script did the rest (looking for the export...). But: From my experience this cannot be automated: You will receive a lot of same exports from different libs or even the same libs but in different version (version number and e.g. debug/release ansi/unicode version etc...) So what lib to add is the question. To decide this you need to have at least *some* more inside knowledge. Sure - there could be a plugin that offers all candidate libs, but this is very platform and compiler specific and you'll need the right tools...

Anyway: This could be done (I'm thinking of a wrapper to my nm - perl approach)... but I'd say publishing this will lead to a lot more problems then it solves because "newbies" will certainly pick the wrong lib... that's murphys law. ;-)

With regards, Morten.

takeshimiya:
On a side note, a well established standard that does the same, already exists and is being used in most Linux libraries.
It's called pkg-config and you can find more info here: http://pkgconfig.freedesktop.org/

Once upon a time, I was making a C::B plugin called pkg-config-manager for rapid editing and viewing of pkg-config files:

MortenMacFly:

--- Quote from: Takeshi Miya on October 10, 2006, 01:44:59 pm ---Once upon a time, I was making a C::B plugin called pkg-config-manager for rapid editing and viewing of pkg-config files:

--- End quote ---
See: Another plugin that got lost on the way... ;-)

Navigation

[0] Message Index

[#] Next page

[*] Previous page