so it is controlled by some heuristics mechanism, i couldn't quickly
find where this is. i suppose it has to do with known sysloc paths.
building the deb n stuff it looks like:
! HB_BIN_INSTALL: /usr/bin
! HB_LIB_INSTALL: /usr/lib/harbour
! HB_INC_INSTALL: /usr/include/harbour
!
I will start over later today.
I want just to say that I did not use HB_*_INSTALL overrides when
building rpm...
It is true that I used HB_*_INSTAL in a previous make; make install
style compilation that I used to check which files were compiled but
it was in another terminal session
The
Hi,
I will start over later today.
I want just to say that I did not use HB_*_INSTALL overrides when
building rpm...
It is true that I used HB_*_INSTAL in a previous make; make install
style compilation that I used to check which files were compiled but
it was in another terminal
On Sun, 3 Jan 2010, francesco perillo wrote:
harbour-static contains the .a libraries
doesn't suse name these kinds of packages -devel, like any
rpm system with good manners does?
--
[-]
mkdir /nonexistent
___
Harbour mailing list (attachment
On Sun, Jan 3, 2010 at 11:20 AM, Tamas TEVESZ i...@extreme.hu wrote:
On Sun, 3 Jan 2010, francesco perillo wrote:
harbour-static contains the .a libraries
doesn't suse name these kinds of packages -devel, like any
rpm system with good manners does?
Well, I will check with other compiler
On Sun, 3 Jan 2010, francesco perillo wrote:
On Sun, Jan 3, 2010 at 11:20 AM, Tamas TEVESZ i...@extreme.hu wrote:
On Sun, 3 Jan 2010, francesco perillo wrote:
harbour-static contains the .a libraries
doesn't suse name these kinds of packages -devel, like any
rpm system with
-devel packages include files that permit to extend core functionalities...
python-devel: Include Files and Libraries Mandatory for Building Python Modules
I don't agree to have a harbour-devel.. .gcc doesn't have a -devel...
it has a compiler package taht includes almost everything...
From what
From what I understand, harbour-lib MUST be installed on all systems
that must run shared compiled Harbour programs.
core and static are instead for programmers-only... I'd merge
these two because static is required anyway if you compile a shared
library !
I agree to merge.
hbmk2 indeed
On Sun, 3 Jan 2010, francesco perillo wrote:
francesco,
honestly this is not intended as an offence, far be from it, but there
are established standards and policies for packaging, which you are
not to reinvent, override or outsmart, but to follow.
opensuse has some nice documentation on
note it says packaging policy, not packaging suggestions.
proper packaging is much more complicated and tricky business than
most of you can even begin to imagine, and it most certainly isn't
just lets shovel a metric shitload of files into an rpm (or deb, or
anything else, for that
Hi Tamas,
I'm not offended since I'm not the original author of the .spec
files... I just wanted to help build the RPMs on Suse (both openSuse
and SLE[D|S]) since I have several running systems at work and at home
that I can use to do such builds.
I was trying to understand how these builds
On Sun, 3 Jan 2010, Viktor Szakáts wrote:
most things below are just scratching the problem-surface, and
definitely need more eyes.
I have a pending commit, which merges core + lib + static
rpms into one. Is this okay?
definitely not.
i think that the proper splitting is something very
definitely not.
i think that the proper splitting is something very close to this (as
i'm primarily familiar with deb, that's what i base the following
upon, but the general principle applies with most every distro, and to
some extent ports, pkgsrc, and whatever other packaging method
On Sun, 3 Jan 2010, Viktor Szakáts wrote:
harbour-utils - hbrun, maybe hbtest
libharbour$shlib_version - libharbour{mt,}.so.x.y.z
libharbour-dev - *.h, *.api, libharbour{mt,}.so (symlink to .x.y.z)
harbour - harbour, hbmk2, *.ch, other stuff that are directly used
when compiling
What is the point of having 'harbour' package, when
nothing useful can be done with it? In any case, hbmk2
needs to be moved to utils since it requires libs to
work.
naturally there are dependencies between them, also external deps as
needed.
Then what is the point of having hbrun
On Sun, 3 Jan 2010, Viktor Szakáts wrote:
Then what is the point of having hbrun without dynamic
libs, when hbrun is built as shared binary in certain
situations, so it cannot work without Harbour dynamic
lib also.
i might be misunderstanding something, but this seems to be
3bis)
I installed the contrib package where harupdf is but I got another error:
contrib/hbhpdf/tests # hbmk2 harupdf.prg
hbmk2: Processing local make script: hbmk.hbm
hbmk2: Processing configuration: /usr/bin/hbmk.cfg
Harbour 2.0.1dev (Rev. 13448)
Copyright (c) 1999-2010,
I suggest you to start over, and if you still have problems,
pls publish your build log so we can see what exactly happened
and what settings were used.
Brgds,
Viktor
On 2010 Jan 3, at 03:07, francesco perillo wrote:
3bis)
I installed the contrib package where harupdf is but I got another
18 matches
Mail list logo
