config/global.mk:1702: *** ! Please set HB_INSTALL_PREFIX and try again..
Stop.
What do I have to assign to HB_INSTALL_PREFIX exactly?
Thank you.
EMG
--
EMAG Software Homepage: http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: http://www.emagsoftware.it/tbosg
The EMG Music page: http://www.emagsoftware.it/emgmusic
F.e.:
C:\myharbour
Viktor
2010/9/15 Enrico Maria Giordano <e.m.gi...@emagsoftware.it>
>
> Building Harbour from latest SVN I get:
>
> config/global.mk:1702: *** ! Please set HB_INSTALL_PREFIX and try again.. Stop.
>
> What do I have to assign to HB_INSTALL_PREFIX exactly?
Target root directory to install Harbour files. See "6. OPTIONS
AVAILABLE WHEN BUILDING HARBOUR" on INSTALL for more details.
Regards,
Vailton Renato
> The root dir of your installation.
>
> F.e.:
> C:\myharbour
Thank you. Can we have a default as it was previously (ie. bin, include and
lib of the SVN checkout directory)?
> Target root directory to install Harbour files. See "6. OPTIONS
> AVAILABLE WHEN BUILDING HARBOUR" on INSTALL for more details.
Thank you. As I said, a default path would be handy, though.
There is no way to find out your preferred default path
outside the Harbour source tree on non-*nix systems.
What would that be? C:\hb? What if that contains an
installed Harbour (or other software) already.
If you want to avoid this issue, just don't use 'install'
when running 'make'. You will still get a fully functional
Harbour this way.
Viktor
> > Thank you. As I said, a default path would be handy, though.
>
> There is no way to find out your preferred default path
> outside the Harbour source tree on non-*nix systems.
Sorry, but previously I get a correct build without using HB_INSTALL_PREFIX.
> What would that be?
As it was previously: the current directory (the SVN checkout one).
> If you want to avoid this issue, just don't use 'install'
> when running 'make'. You will still get a fully functional
> Harbour this way.
I just tried without 'install' but I don't get the correct build in bin,
include and lib directories, sorry.
You need it now to create a correct installed setup with
COPYING and rest of supplementary files. It now even
simpler, since instead of setting HB_INSTALL_BIN,
HB_INSTALL_LIB, etc, it's enough to set HB_INSTALL_PREFIX.
>> What would that be?
>
> As it was previously: the current directory (the SVN checkout one).
'install'-ing inside the SVN tree has severe drawbacks
so it has been shut down. But, as I told, it now works
the same without using 'install', so it's just not needed.
IOW all files (bin, header, libs) will get into their correct
"live" position inside the SVN tree, by using plain 'make'
without 'install. [ NOTE: Make sure to use 'hb<lib>.hbc'
instead of '-lhb<lib>' to refer to contribs, so that the headers
will be found this way. ]
>> If you want to avoid this issue, just don't use 'install'
>> when running 'make'. You will still get a fully functional
>> Harbour this way.
>
> I just tried without 'install' but I don't get the correct build in bin,
> include and lib directories, sorry.
You have them in the SVN dir, you don't need more.
Just try to call 'hbmk2 <myapp.prg>' from bin/win/<comp>/ and
you will understand.
If you want to create a separate tree with the distributable
files (bin, header, lib) only, you need to use 'install', and
set 'HB_INSTALL_PREFIX' to the root dir of that tree.
But again, this is OPTIONAL.
Viktor
> > Sorry, but previously I get a correct build without using
> > HB_INSTALL_PREFIX.
>
> You need it now to create a correct installed setup with
> COPYING and rest of supplementary files. It now even
> simpler, since instead of setting HB_INSTALL_BIN,
> HB_INSTALL_LIB, etc, it's enough to set HB_INSTALL_PREFIX.
Ok, no problem for me, but previously I have not to set any of the above
variables.
> > As it was previously: the current directory (the SVN checkout one).
>
> 'install'-ing inside the SVN tree has severe drawbacks
> so it has been shut down.
I didn't notice any problems but ok, I understood.
> But, as I told, it now works
> the same without using 'install', so it's just not needed.
I alredy tried without using 'install' but did not get the files in the
usual directories (bin, include and lib of the SVN tree).
> IOW all files (bin, header, libs) will get into their correct
> "live" position inside the SVN tree, by using plain 'make'
> without 'install. [ NOTE: Make sure to use 'hb<lib>.hbc'
> instead of '-lhb<lib>' to refer to contribs, so that the headers
> will be found this way. ]
I don't understand. Anyway no, I don't get the files in their correct
positions (they were bin, include and lib of the SVN tree previously).
> > I just tried without 'install' but I don't get the correct build in bin,
> > include and lib directories, sorry.
>
> You have them in the SVN dir, you don't need more.
I don't understand.
> Just try to call 'hbmk2 <myapp.prg>' from bin/win/<comp>/ and
> you will understand.
I never used hbmk2, why I'd start using it now?
> If you want to create a separate tree with the distributable
> files (bin, header, lib) only, you need to use 'install', and
> set 'HB_INSTALL_PREFIX' to the root dir of that tree.
Ok, that's fine.
> But again, this is OPTIONAL.
It looks not OPTIONAL to me. What am I missing?
In precedenza era necessario dare il HB_INSTALL_DIR=/<path>; make
clean ; make ; make install e la procedura di build copiava
all'interno dell'albero <path> tutti i file necessari. Un passaggio
importante era che la copia includeva i files .h/.ch presenti in
contrib/<dir>.
Quindi se facevi un make install con la INSTALL_DIR puntata sulla
stessa directory dei sorgenti, ti trovavi con i file .h/.ch delle
contrib duplicati, una volta nella main include dir, e una volta
dentro la contrib dir.
Se facevi un svn update, rischiavi seriamente casini, perché durante
la compilazione di harbour magari si usava il .h di contrib, durante
la compilazione del tuo programma invece usavi quella nella main
include dir... puoi immaginare i casini....
>> But, as I told, it now works
>> the same without using 'install', so it's just not needed.
invece di puntare alle librerie (-lhb<lib>) all'interno del tuo file
di progetto hbmk2, punta ai file hb<lib>.hbc. All'interno di questo
file ci sono direttive che comunicano a hbmk2 varie cose, fra le quali
le lib/include dir della libreria in oggetto (informazione che hbmk2
mette a disposizione di harbour durante la compilazione del progetto)
e il nome della libreria (che hbmk2 inserisce automaticamnete con
-hb<lib>). Inoltre se la libreria <lib> necessita di altre librerie
per funzionare, queste vengono specificate nel file .hbc e
automaticamente incluse in fase di link... ad esempio il file
hbhpdf.hbc contiene:
incpaths=. // aggiunge all'invocazione di harbour
-I<path alla directory corrente> che hbmk2 calcola a runtime
libs=${hb_name}${__HB_DYN__} // aggiunge -lhbhpdf ($DYN è per le
dinamiche, non ho approfondito)
libs=libhpdf // aggiunge -llibhpdf
libs=png // aggiunge -lpng
In precedenza libhpdf e png le dovevi aggiungere esplicitamente nel
file di progetto (perché sono obbligatorie e non avresti potuto
linkare), ora punti a hbhpdf.hbc e ci pensa lui.
Inoltre hbmk2 calcola la posizione di riferimento a runtime. Quindi se
sposti da c:\harbour a f:\compilers\harbour l'unica cosa che devi
fare, l'UNICA è cambiare la path verso la nuova directory. Poi ci
pensa hbmk2 a fare tutti i calcoli delle posizioni....
Credimi, è una figata. Sto modificando in questi giorni gli script di
build del mio programma e mi sembrano semplificati
> I never used hbmk2, why I'd start using it now?
oooops, mi era sfuggita questa riga....
>> If you want to create a separate tree with the distributable
>> files (bin, header, lib) only, you need to use 'install', and
>> set 'HB_INSTALL_PREFIX' to the root dir of that tree.
>
> Ok, that's fine.
>
>> But again, this is OPTIONAL.
>
> It looks not OPTIONAL to me. What am I missing?
Ok, almeno è servito per dirti cose è per te "missing"... :-)
Se ne hai la possibilità, prova ad usare hbmk2... è comodo...
Ciao
Francesco
Il 16 settembre 2010 09:58, francesco perillo <fper...@gmail.com> ha scritto:
>
> Se ne hai la possibilità, prova ad usare hbmk2... è comodo...
>
--
Massimo Belgrano
It's since long the only one documented (in INSTALL doc) variable
you need to set when doing 'install'.
>> 'install'-ing inside the SVN tree has severe drawbacks
>> so it has been shut down.
>
> I didn't notice any problems but ok, I understood.
We have, on the list. Many users installed into the SVN tree,
but did so inconsistently which caused random build errors
due to outdated copies installed into the central include directory.
For those users who _always_ used 'install' after doing a 'make',
this wasn't a problem, but apparently, few users did it this way,
and for sure there was no guarantee that such mistake is not
made. Now there is.
>> But, as I told, it now works
>> the same without using 'install', so it's just not needed.
>
> I alredy tried without using 'install' but did not get the files in the
> usual directories (bin, include and lib of the SVN tree).
If by "usual" you mean the dirs we used 10 years ago,
yes, there have been changes, binaries are created in
'bin/<plat>/<comp>' and libs are created in 'bin/<plat>/<comp>',
so multicompiler and multiplatform trees are supported
out of the box. The include dir didn't change, so for sure
these are there (only contrib headers are not copied, and
that's the reason you need to use .hbc files to refer to
contribs).
All above changes should be transparently handled by
hbmk2 tool. If you use other build tool, you might need to
adapt your build setting accordingly, or resort to setting
HB_INSTALL_PREFIX and use 'install'.
>> > I just tried without 'install' but I don't get the correct build in bin,
>> > include and lib directories, sorry.
>>
>> You have them in the SVN dir, you don't need more.
>
> I don't understand.
I pass the opportunity to others. Looks like I'm wasting
our time here.
>> Just try to call 'hbmk2 <myapp.prg>' from bin/win/<comp>/ and
>> you will understand.
>
> I never used hbmk2, why I'd start using it now?
You don't have to.
>> If you want to create a separate tree with the distributable
>> files (bin, header, lib) only, you need to use 'install', and
>> set 'HB_INSTALL_PREFIX' to the root dir of that tree.
>
> Ok, that's fine.
>
>> But again, this is OPTIONAL.
>
> It looks not OPTIONAL to me. What am I missing?
For example I don't need it on any platforms. You apparently
do. That's called optional.
Viktor
... outdated copies of *headers* installed ...
Viktor
Hi,
> >> As it was previously: the current directory (the SVN checkout one).
> >'install'-ing inside the SVN tree has severe drawbacks
> >so it has been shut down.
> I didn't notice any problems but ok, I understood.
Few times in the past people reported very strange errors during
build process and after some investigation we found that the problems
were created only in their local Harbour CVS/SVN copy due to installing
files into source code tree, i.e. header files from contrib tree
were copied to core include directory so it was possible that they were
used instead of the local ones updated after svn/cvs update so the 1-st
clean build were broken. In few cases people mixed header files from
old Harbour version and new one and even some of them mixed Harbour
and xHarbour header files.
AFAIR you reported some problems which suddenly disappeared after next
clean build so it's highly possible that you exploited this problem and
I believe that you are finding this modification as very important
protection against broken builds.
> I alredy tried without using 'install' but did not get the files in
> the usual directories (bin, include and lib of the SVN tree).
include directory is as it was. We only fixed the problem with
coping contrib header files to this directory what was breaking
1-st clean build after updating SVN repository.
binaries are in:
./bin/<platform>/<compiler>
and libraries in:
./lib/<platform>/<compiler>
such solution allows to create Harbour binaries for different
C compilers and also cross platform builds, i.e. DOS, WINDOWS,
OS2 and LINUX binaries using OpenWatcom with one of the above
platform so the binaries are there but deeper in the path.
It's also very important extensions.
> I never used hbmk2, why I'd start using it now?
You do not have to but it greatly simplify application build process
for users and safes core developers time because it strongly reduced
user questions about build problems.
It also has some features unavailable in other build process,
i.e. support for i18n and automatic generating/merging of .po
and .hbl files, automatic dependency detection (see incremental
builds) and many more, etc.
HBMK2 uses built-in harbour compiler so in the future it may
give some compile time optimization for functions which calculate
returning value using passed parametes only and do not make any
other operations so for constant parameters they can be executed
to calculate the result at compile time.
Such optimization is possible because compiler is linked with HVM
so we can evaluate such functions during compilation. HBMK2 will
only have to pass list of such functions to compiler, i.e. if it
passes HB_CRC32() then for code like:
QOUT( HB_CRC32( "TEXT" ) )
compiler can evaluate HB_CRC32( "TEXT" ) and generate code for:
QOUT( 220088947 )
The only one thing I would like to see is rewriting HBMK2 code
in a way which allows to easy add new compilers/platforms.
Such functionality seems to be very good candidate for OOP code.
We can create basic OS and compiler classes and use inheritance
for some mutations.
Anyhow if you do not plan to use it then it's not sth what you
will find interesting.
> It looks not OPTIONAL to me. What am I missing?
That for many years you were mixing old and fresh header files
in include directory in Harbour and xHarbour builds what can be
source of some periodical problems when old and new header files
were not compatible and wrong one were used for compilation.
It's also the answer why in the past 1-st clean build sometimes
was not realy _clean_ ;-)
best regards,
Przemek
> > I alredy tried without using 'install' but did not get the files in the
> > usual directories (bin, include and lib of the SVN tree).
>
> If by "usual" you mean the dirs we used 10 years ago,
No, the dirs used for years till two days ago. If now such dirs are no more
used, fine, but where is the doc about this change?
> yes, there have been changes, binaries are created in
> 'bin/<plat>/<comp>' and libs are created in 'bin/<plat>/<comp>',
> so multicompiler and multiplatform trees are supported
> out of the box. The include dir didn't change, so for sure
> these are there (only contrib headers are not copied, and
> that's the reason you need to use .hbc files to refer to
> contribs).
>
> All above changes should be transparently handled by
> hbmk2 tool. If you use other build tool, you might need to
> adapt your build setting accordingly, or resort to setting
> HB_INSTALL_PREFIX and use 'install'.
Ok, I will use HB_INSTALL_PREFIX from now on, no problem.
> I pass the opportunity to others. Looks like I'm wasting
> our time here.
I'm simply wondering why my batch won't work anymore. If you consider a
waste of time to answer to this problem then just don't ask. For your
information, the batch I used for ages was your suggestion. Here it is:
@ ECHO OFF
SET PATH=e:\bcc55\bin;%PATH%
mingw32-make clean install > make_gnu.log 2>&1
From yesterday it won't work anymore.
> Few times in the past people reported very strange errors during
> build process and after some investigation we found that the problems
> were created only in their local Harbour CVS/SVN copy due to installing
> files into source code tree, i.e. header files from contrib tree
> were copied to core include directory so it was possible that they were
> used instead of the local ones updated after svn/cvs update so the 1-st
> clean build were broken. In few cases people mixed header files from
> old Harbour version and new one and even some of them mixed Harbour
> and xHarbour header files.
> AFAIR you reported some problems which suddenly disappeared after next
> clean build so it's highly possible that you exploited this problem and
> I believe that you are finding this modification as very important
> protection against broken builds.
I'm not against improving Harbour, of course. The following batch was an old
your (or Viktor) suggestion:
@ ECHO OFF
SET PATH=e:\bcc55\bin;%PATH%
mingw32-make clean install > make_gnu.log 2>&1
What is the recommended way now? I'm willing to use hbmk2 if it is as simple
as the above. Can you show me the right, current way to build Harbour,
please? I will immediately adopt it.
Nothing changed in Harbour in last two days.
>> I pass the opportunity to others. Looks like I'm wasting
>> our time here.
>
> I'm simply wondering why my batch won't work anymore. If you consider a
> waste of time to answer to this problem then just don't ask. For your
> information, the batch I used for ages was your suggestion. Here it is:
I didn't ask anything from you. You asked for help then
you keep arguing and ignoring the answers.
Viktor
Drop 'install' or set HB_INSTALL_PREFIX. What's so complex
about that?
Harbour changes. So what I've personally advised you "ages"
ago might not be true _now_. So instead of arguing, I'd suggest
to try to read the answers and grasp the new information.
Viktor
Hi,
> I'm not against improving Harbour, of course. The following batch
> was an old your (or Viktor) suggestion:
>
> @ ECHO OFF
> SET PATH=e:\bcc55\bin;%PATH%
> mingw32-make clean install > make_gnu.log 2>&1
If you want to execute 'install' make phase then you have
to inform were files should be installed using HB_INSTALL_PREFIX
Please only remember that you should not install files into your
local copy of SVN source tree like it was before because in such
case you can duplicate header files and then create broken Harbour
binaries like it was before.
> What is the recommended way now? I'm willing to use hbmk2 if it is
> as simple as the above. Can you show me the right, current way to
> build Harbour, please? I will immediately adopt it.
You do not have to use HBMK2.
Anyhow I suggest you to look at it in some spare time.
It can greatly simplify build process for your own application
and libraries.
best regards,
Przemek
I agree with this goal. Not with the OOP approach though,
because it makes code very fragile due to no compile time
checking of method calls. I could imagine some pseudo-OOP
approach to achieve this goal. Or a script-based approach,
where you define targets using some syntax. Anyhow it's
quite huge task, but at least now the scope of the problem
domain can be seen well.
Viktor
This is a long standing issue, solving this would be a great improvement to
harbour.
I don't know how hard it could be, though.
Best regards.
Maurilio
--
__________
| | | |__| Maurilio Longo
|_|_|_|____| farmaconsult s.r.l.
oObject:mymethod( )
is a valid call ? if mymethod is actually a method of oObject ?
How could achieve this since you can "attach" methods and members to
objects at runtime ?
Or am I missing the point ?
> > @ ECHO OFF
> > SET PATH=e:\bcc55\bin;%PATH%
> > mingw32-make clean install > make_gnu.log 2>&1
>
> If you want to execute 'install' make phase then you have
> to inform were files should be installed using HB_INSTALL_PREFIX
> Please only remember that you should not install files into your
> local copy of SVN source tree like it was before because in such
> case you can duplicate header files and then create broken Harbour
> binaries like it was before.
What is the recommended way? Do I have to create a directory 'MyHarbour' and
set HB_INSTALL_PREFIX to it? If yes, can it resides inside SVN tree? I hate
to have directories scattered here and there...
2010/9/16 Enrico Maria Giordano <e.m.gi...@emagsoftware.it>:
>
> -----Messaggio Originale----- Da: "Przemysław Czerpak" <dru...@acn.waw.pl>
> A: <harbou...@googlegroups.com>
> Data invio: giovedì 16 settembre 2010 12.10
> Oggetto: Re: [harbour] HB_INSTALL_PREFIX
>
>
>> > @ ECHO OFF
>> > SET PATH=e:\bcc55\bin;%PATH%
>> > mingw32-make clean install > make_gnu.log 2>&1
>>
>> If you want to execute 'install' make phase then you have
>> to inform were files should be installed using HB_INSTALL_PREFIX
>> Please only remember that you should not install files into your
>> local copy of SVN source tree like it was before because in such
>> case you can duplicate header files and then create broken Harbour
>> binaries like it was before.
>
> What is the recommended way? Do I have to create a directory 'MyHarbour' and
> set HB_INSTALL_PREFIX to it? If yes, can it resides inside SVN tree? I hate
> to have directories scattered here and there...
From what I've used here can be anywhere, JUST is not recommended to
generate the SAME PATH where is the SVN sources resides. Now I see no
problems using a nested folder and if you read carefully the
information contained in the INSTALL file in the "6. OPTIONS AVAILABLE
WHEN BUILDING HARBOUR" as I quoted above.
The INSTALL file contains many important informations about Harbour
and several helpful tips and experiences, compare it with the
CHANGELOG file will be great to help on future questions.
Regards,
Vailton Renato
> > What is the recommended way? Do I have to create a directory 'MyHarbour'
> > and
> > set HB_INSTALL_PREFIX to it? If yes, can it resides inside SVN tree? I
> > hate
> > to have directories scattered here and there...
>
> From what I've used here can be anywhere, JUST is not recommended to
> generate the SAME PATH where is the SVN sources resides. Now I see no
> problems using a nested folder
Thank you.