On 12/01/2015 18:30, Olivier Brunel wrote: Hi Olivier,
I usually build things with -j4, but with e.g. execline I get an error: make: *** No rule to make target '-lexecline', needed by 'background'. Stop. make: *** Waiting for unfinished jobs....
Yeah, that's a known problem, and I think the issue is with make.
In that case, I think you need to use e.g. libexecline.a instead, so that make can order things properly even with parallel jobs. I tried replacing -lexecline with $(STATIC_LIBS) in deps.mak and I can `make -j4` just fine. Of course this won't work when building with --disable-allstatic, where other changes might be in order.
That's the very point: I need a solution that works with both libexecline.a and libexecline.so. If it was only me, I'd use libexecline.a everywhere, but you know how distributions love dynamic linking, so I want to make it easily accessible. GNU make is supposed to replace -lexecline with the static or the dynamic version depending on what it finds first, and my Makefile has vpath instructions at the beginning, so it's definitely supposed to work - but apparently, vpath search doesn't mesh well with make -j, and this is not documented in the GNU make manual. I will try to come up with a workaround.
Then, I'm trying things with skalibs & co to see how it works, but there isn't always (lots of) documentation. For instance, I'm not sure how the whole buffered IO API work/are meant to be used; Is there any doc about this somewhere I could read?
Ah, stop pressing where it hurts. :( skalibs' documentation is my main pain point. I originally made the skalibs package as a collection of functions I was using all the time; my goal was centralization and reusability of code - and it was successful in that aspect, it's definitely the right choice in retrospect. However, my initial goal was to spend more time on "real" code, application code that does stuff, and that has been a huge failure. I've spent more time on skalibs than on anything else. As every developer knows, writing code is more fun than writing doc. I try to write complete documentation for applicative packages, because a program is useless if people don't know how to use it. But making skalibs really usable by other people than myself came as an afterthought, so I did not originally spend time writing documentation along the code. And now there's a huge backlog of code that needs to be documented, and I should really do it, and I know it, and it makes me feel guilty, but at the same time, writing more skalibs documentation means *even more* time spent on skalibs and even less on real code. The only thing I can say is that documentation *will* come... one day. I don't want to make any deadline promises - I'm bad at keeping those. But if you have some project that you're really interested in using skalibs APIs for, and the lack of doc is a show-stopper, I can certainly be prodded, pushed, enticed, bribed or threatened to get to work on the parts you need. Faster. For "buffer" in particular, the inspiration comes from DJB's API: http://cr.yp.to/lib/buffer_get.html http://cr.yp.to/lib/buffer_put.html skalibs' buffer.h has evolved a lot since, and has a totally different implementation (and now things like buffer_putalign are not needed anymore), but the idea is the same. The goal of the buffer API is to be lighter and more reliable than stdio (as in, properly reporting the number of written characters, for instance), andusable with non-blocking IO as well as blocking IO. If you have specific questions on how to achieve something, it's generally easier to get me to answer on this list than to get me to write a doc page. Interactivity has immediate rewards from me (user feedback) and I'm a sucker for those.
Also, I've made a little thing that works say somewhat like execline's define, and tried to compile it, but it fails. I get a few errors such as: /usr/lib/execline/libexecline.a(el_transform.o): In function `el_transform': (.text+0x112): undefined reference to `satmp' (...) % gcc test.c -static -Wall -lskarnet -lexecline -L/usr/lib/skalibs -L/usr/lib/execline
That's a classic linker trap. You need to put the lower-level libraries *after* the higher-level libraries on gcc's invocation command line. Try "-lexecline -lskarnet" instead of "-lskarnet -lexecline". That should solve all your symbol-related problems.
Yeah, back to stralloc, in your code (e.g. s6) you seem to use it (satmp) at times, but I have no idea how this works. Obviously, it's also something libraries (at least libexecline) might use, so is it meant for app or to be an internal thing that you abuse in your own code? How safe is it to use if library functions can use it?
satmp is a global stralloc. The point of satmp is to have a unique place for temporary allocations that have to use the heap for some reason, instead of making strallocs all over the place and freeing them. Reusing the same storage space (and freeing it at the end) is cheaper than having series of malloc/free, and it makes it easier to keep track of your heap. You can use it safely provided you're using it as a stack: * unsigned int oldlen = satmp.len * stralloc_catb whatever you want to satmp, whatever is above oldlen is free for you to use. What is below oldlen, however, is data needed by your caller, and you can't touch it. * satmp.len = oldlen Always restore satmp.len when you exit your function, even in error conditions. But then again, globals are ugly, so it's probably more trouble than it's worth. It's certainly easier and safer for you to make your own private stralloc instead of bothering with satmp for some micro optimization. -- Laurent
