neither of them are widely used, glib is pretty large(1MB at least, OK for desktop but too large for embedded, for example) and apr's function is limited.
clib can let you integrate small pkgs at will at source level, sometimes it is very handy and useful.
Language package managers take care of versioning/downloading the library from a central source into a project-specific place where the toolchain will find it.
AFAIK for C, this is handled by your linux distribution, and for any libraries that are not part of your distro you would be downloading the header and object files / pointing your Makefile at them by hand.
Next to it being a fun language, what I love most about C is the lack of package managers, or rather, letting the operating system mange the library packages.
It's refreshing to know that the code I write can be build by anyone, it runs on Linux, Windows, Macs, heck, my stuff has been ported to Aros, FreeBSD, Playstation Portable, Pandora, GP2X, GCW-Zero, Haiku, Amiga OS4, Canoo, Dingux, Android and some Motorola phones, probably exactly because it uses standard library and only one or two third-party libs which are widely available on any platform.
I feel like one of the big reasons package managers aren't great with C is because of the way namespaces work.
It's not easy to have a medium-large codebase and just freely add a dependency because maybe this library causes variable or function name clashes. Even worse would be a macro that screws with your code.
There isn't even a simple solution like preprocessing everything in the downloaded library and adding a known prefix to every namespace encroaching identifier I think.
Except it isn't because why would gtk need to prefix their functions and structs with these ugly names? Namespaces is the answer to solving problems arising from a lack of namespaces.
There is a certain irony in the source code for a package manager expecting the key package needed to build that package manager to have been installed by some other package manager.
19 comments
[ 4.1 ms ] story [ 21.5 ms ] threadThat place already exists. In fact, at least two such places exist: GLib and APR.
Also, this is not how C development workflow works.
clib can let you integrate small pkgs at will at source level, sometimes it is very handy and useful.
AFAIK for C, this is handled by your linux distribution, and for any libraries that are not part of your distro you would be downloading the header and object files / pointing your Makefile at them by hand.
It's refreshing to know that the code I write can be build by anyone, it runs on Linux, Windows, Macs, heck, my stuff has been ported to Aros, FreeBSD, Playstation Portable, Pandora, GP2X, GCW-Zero, Haiku, Amiga OS4, Canoo, Dingux, Android and some Motorola phones, probably exactly because it uses standard library and only one or two third-party libs which are widely available on any platform.
It's not easy to have a medium-large codebase and just freely add a dependency because maybe this library causes variable or function name clashes. Even worse would be a macro that screws with your code.
There isn't even a simple solution like preprocessing everything in the downloaded library and adding a known prefix to every namespace encroaching identifier I think.
> gtk_app_chooser_widget_set_show_recommended
> gtk_tree_model_filter_convert_child_iter_to_iter
gtk_app_chooser_widget_set_show_recommended
gtk::app::chooser::widget::set_show_recommended
gtk.app.chooser.widget.set_show_recommended