PC Toledo

Mas num resumo geral:

É todo mundo programador.

Criar BATs, scripts, ou arquivo HBP, acaba sendo o mesmo que programar.

Então todos SABEM.
O problema é que tá todo mundo ficando velho, velho sabe mais que todo mundo, mas ACHA que não sabe.

NADA MUDOU nestes 30 anos de DOS/Windows.
PATH continua o mesmo, BAT continua o mesmo.
Lista de arquivos e pastas continuam o mesmo.

É só acrescentar a indicação na frente, se trata-se de arquivo, pasta, lib, ou o que for.

arquivo PRG... não precisa nada, só o nome
arquivo CH... precisa dizer em que pasta está, isso é include com I, então -I\pasta\include
arquivo LIB... precisa dizer o nome, isso é LIB com L, então -lnomelib
arquivo LIB... precisa dizer a pasta, isso é LIB com L, então -L\pasta\lib
arquivo RC... precisa dizer o nome
arquivo C.... precisa dizer o nome
arquivo HBP... isso é subprojeto Harbour, só dizer o nome

No geral é só isso que entra numa compilação/linquedição.
O HBP é uma lista disso.
o HBMK2 usa uma lista disso.

O que tem de complicado em criar uma lista?
Por acaso não sabe o que precisa a sua lista?
Boa oportunidade pra finalmente saber o que faz parte de sua lista, e o mínimo que deveria saber.
Sem a lista, e o conteúdo indicado na lista, simplesmente não existe aplicativo, então a melhor coisa é ter essa lista.

Certamente, Quintas, na medida em que a gente vai mexendo e testando, vamos melhorando o entendimento.

Grato a todos pelas dicas.

O texto é pra todos de um modo geral.

Dá pra acrescentar algo interessante agora pra complementar:

Se o HBP tem o que o seu aplicativo usa...
Pense bem... quem é que sabe o que o seu aplicativo usa?

É você mesmo.

Conforme vai usando mais recursos, vai acrescentando na lista.
Igual faz com o menu principal do aplicativo, quando acrescenta mais opções.
Acrescentou opções, acrescenta no menu, acrescenta no HBP.

Considere o HBP como sendo o "menu" do seu aplicativo.
É dele que sai tudo.

Podemos ajudar, mas no final é você que vai responder o que faz parte da lista, e aonde estão as coisas da lista.

Uia... compliquei um pouco mais pra facilitar.... rs

Só lembrando que na minha máquina hwgui, hmg, hmg extended e oohg não são criadas iguais às originais.
Aqui elas tem uma lib única, e minha errorsys entra no lugar da delas
Na máquina de vocês, será indicar a lista das LIBs

um arquivo hbmk.hbc na pasta d:\harbour\bin, indicando a pasta d:\cvsfiles\allgui\allgui como pasta de lib
E na pasta allgui, HBCs pra hmg3, hmgs, hwgui e oohg

por fim, vou na pasta \hmgs\applications\super, e digito:

hbmk2 *.prg *.rc hmgs.hbc xhb.hbc

Pronto. Não precisou nem hbp para o projeto.

Legal isso.

Acho importante destacar o seguinte:

É informar PATH aonde estão os arquivos CH, LIB, e no caso das LIBs informar qual o nome delas.
Mesmo que deixem automático... é bom decorar isso.
Nem tem muito o que decorar, é só indicar nome de pasta (PATH)e nome de arquivo, pra cada tipo de arquivo.
E no caso dos EXEs.... isso fica no SET PATH do Windows.

Isso é no Harbour, porque no XHarbour ainda não fizeram um HBMK2....
Mas são só estes arquivos, seja pra compilar HMG3, HMGS, HWGUI ou OOHG.

Talvez de diferente no hbc seja o uso de ${hb_comp}.
Isso se refere ao compilador.
Se eu usar msvc, vai buscar em lib\win\msvc
O mesmo pra mingw, bcc, mingw64, msvc64, etc.
Já fica automático, não importa qual ou quais compiladores C existam na máquina.

E pra quem ficou curioso, os HBP que geram as LIBs.
Nada diferente: lista de arquivos, lista de pastas.
E lib gerada em pasta conforme compilador ${hb_comp}.
Aqueles arquivos comentados na HWGUI, é porque assim compila com MSVC ou MINGW, mas se incluir aqueles arquivos, só compila com MINGW.
Deve ter um jeito de colocar IF no hbp, mas não cheguei a olhar como faz. Algo como: IF ${hb_comp} == mingw ....

Depois que postei dei uma pesquisada, e é mais fácil do que eu pensava.
Só acrescenta se NÃO for MSVC.

É isso aí, Quintas !!!

Talvez exista uma carência de um passo-a-passo para quebrar um pouco do impacto inicial sobre trabalhar com hbp, hbc, etc. Porque quem possui pouca familiaridade, leva um susto e acaba desanimando. Só depois de algum tempo que se percebe a praticidade de usar.

A propósito, Quintas, sei que não tem a ver com o tópico, sobre gerar as libs do sistema. Se eu tenho um sistema com vários módulos e funções próprias, tenho a opção de gerar a lib dessas funções, certo ? Qual é vantagem de gerar essas libs próprias com relação a continuar compilando tudo em código fonte dentro do projeto ?

Obrigado,

Maickon Sato

Um ganho de velocidade talvez.
Ao invés de verificar vários fontes da LIB, pega direto a lib sem verificar esses fontes.

Mas eu acabo verificando a lib também, pra não esquecer de atualizar.... rs
incluo a lib como subprojeto, e acaba sendo testada se está atualizada - libjose.hbp é o sub-projeto, e -llibjose acrescenta a lib.

Mas tenho um caso ANORMAL, aonde isso se torna obrigatório:
Se compilar junto, os arquivos CH de uma LIB atrapalham a outra LIB.
A saida foi dividir por LIB.
Mas é totalmente fora do normal isso, trata-se de teste misturando as GUIs.

Atualização saindo forno sobre hbmk2:

+ initialize target .hbl files with empty content in case any of these
is missing, _before_ the .prg compiler pass. This ensures that the
build will not fail due to missing .hbl files in case the source
code depends on them, f.e. by '#pragma __binarystreaminclude'-ing
them to embed them in the executables. This feature will ensure that
the build is successful, but to include non-empty .hbl files with
the desired content, a subsequent build is required (.hbl files are
generated after the .prg compilation phase). A warning is shown to
inform the user about that.
In short: It became easier to bootstrap projects that embed .hbl
files into their own binaries.

Olhando o código do hbmk2 não achei a "function ou procedure main" como é que ele é gerado?

Ops, achei FUNCTION _APPMAIN( ... ) aka FUNCTION MAIN

Se entendi direito, tem a ver com o uso de resources.
Vai permitir gerar o EXE, mesmo faltando resource, mas vai avisar.

Esta parte:

#pragma __binarystreaminclude

Quintas,

Ainda não entendi como funciona o uso do hbl, enfim tem muita coisa pra descobrir.

É porque não é pra entender..... rs
São gerados automaticamente.

a subsequent build is required (.hbl files are
generated after the .prg compilation phase).

Por favor coloque como HMEE e não como HMG Extended. Não está errado também essa definição e sabemos que este é um fork (versão em paralelo) do HMG.
Porque acho que para os menos avisados confundem com HMG (talvez o outro autor ainda deseje que seja assim).

Deixei passar seu post antes.

A HMG não vai chegar em 4, porque foi criada a 4 pra QT, então dá pra deixar HMG3.

A extended:
XHMG ou HMGX poderia parecer HMG pra xHarbour, além de HMGx parecer indicar qualquer versão.
Até usei HMGS, mas ao falar sobre todas as HMGs, confunde se seriam todas ou somente a extended.
hmg3 pra minigui 3.x, hmge pra minigui extended, acho que dá pra acostumar melhor.