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
Received on Mon Jan 12 2015 - 20:27:39 UTC