Hi,
Yes, I'm still thinking about this. It's probably
inevitable to add some tricks for proper lib name
detection/usage. The details are unclear yet,
for sure it's an option to continue to use our own
name, so whichever will make things easier to manage.
Brgds,
Viktor
On 2009.09.10., at 11:55,
On Thu, 10 Sep 2009, Szak�ts Viktor wrote:
Hi,
> One consequence is that they'd have to be renamed
> to their original lib names (dropping 'hb' prefix).
> Plus some additional hbmk[2] tricks will be required.
If you can resolve potential problems with name conflicts
when one library with the sam
Thank you Phil.
Brgds,
Viktor
On 2009.09.10., at 01:08, Phil Barnett wrote:
On Thu, 2009-09-10 at 01:02 +0200, Viktor Szakáts wrote:
Hi All,
There is a pending item on my TODO list to move
hbzlib and hbpcre sources under /external tree.
At the same time the detection of externally available
On Thu, 2009-09-10 at 01:02 +0200, Viktor Szakáts wrote:
> Hi All,
>
> There is a pending item on my TODO list to move
> hbzlib and hbpcre sources under /external tree.
>
> At the same time the detection of externally available
> versions could also be added, and possibility to override
> them wi
Hi All,
There is a pending item on my TODO list to move
hbzlib and hbpcre sources under /external tree.
At the same time the detection of externally available
versions could also be added, and possibility to override
them with usual HB_INC_* vars also. It's probably healthier
to use these on *ni
