1 |
On Wednesday, June 09, 2010 01:34:27 Michał Górny wrote: |
2 |
> On Tue, 8 Jun 2010 18:44:55 -0400 Mike Frysinger wrote: |
3 |
> > On Sunday, June 06, 2010 03:45:51 Michał Górny wrote: |
4 |
> > i dont know anything about zpaq, but it looks like you're installing |
5 |
> > the bare .o files ? that's a bit odd. usually things like this are |
6 |
> > installed as static archives for people to link in ... |
7 |
> |
8 |
> A single .o file exactly. ZPAQ in runtime can 'optimize' itself through |
9 |
> creating compression scheme sources and calling 'zpaqmake' to compile |
10 |
> it. |
11 |
> |
12 |
> The default 'zpaqmake.bat' included with it compiled these schemes |
13 |
> along with 'zpaq.cpp' for the executable stub. I've decided that it'd |
14 |
> be better to provide already compiled stub. |
15 |
|
16 |
if it's all internal to zpaq itself (i.e. packages arent externally pulling in |
17 |
the files w/out help), then the .o's are fine. |
18 |
|
19 |
> Honestly, I didn't think long about the format. I guess .a could be |
20 |
> better, or maybe even a shared library -- but GNU make doesn't seem to |
21 |
> have implicit rules for these formats. |
22 |
|
23 |
there are implicit rules for generating archives, but iirc, they dont work in |
24 |
parallel. shared libs obviously dont exist because this is highly target |
25 |
specific -- this is why libtool exists in the first place. |
26 |
-mike |