Отправлено: 08.08.11 10:55. Заголовок: hbmk2

Как задать сборку библиотеки, если сырцы находятся в разных каталогах ?
Причем в файле hbp не хотелось бы указывать абсолютный путь

Хотелось бы задать переменные окружения:

set HB_CT=\harbour\contrib\hbct\
set HB_WIN=\harbour\contrib\hbwin\

и затем их использовать в *.hbp, что-то вроде:

$(HB_CT)addascii.c
...
$(HB_WIN)axcore.c

 Отправлено: 09.08.11 12:10. Заголовок: Как вариант в каждом..

Как вариант в каждом каталоге создать hbm с нужными файлами, а в главном hbp указать эти hbm.
Только что проверил на letodb
========================
rddleto.hbp
========================
#
# $Id: rddleto.hbp,v 1.3.2.3 2011/08/01 16:10:56 ptsarenko Exp $
#

# static lib
-hblib
# shared lib, dll or so
#-hbdynvm
#-shared

-nohbc
-inc
-olib/rddleto
-iinclude
-n -w -q0 -es2

source/client/leto1.c
source/client/letomgmn.c
source/client/rddsys.prg

source/common/common.hbm
end ===================================

common.hbm (source/common/)
======================
blowfish.c
common_c.c
hbip.c
net.c

end===============================

Потом hbmk2 rddleto.hbp letodb.hbp и все нормально.

 Отправлено: 09.08.11 15:50. Заголовок: Столкнулся с какой-т..

Столкнулся с какой-то совершенно бредовой ситуацией
Использую релиз Harbour 3.0
С помощью hbmk2 собираю свою либу, в которой более сотни модулей.
В этих модулях (prg) часто встречаются конструкции вида:

#ifdef __HARBOUR__
...
#endif

#ifndef __HARBOUR__
...
#else
...
#endif

Заметил, что многие модули были скомпилированы, как будто __HARBOUR__ не определен.
Поставил флажок -p, посмотрел ppo - действительно так.
Причем первые несколько модулей собираются с __HARBOUR__ а начиная где-то с 9-го - без.
Если я правлю 9-й модуль, и запускаю hbmk2, то перекомпилируется только он один, и с
уже определенным __HARBOUR__
Даже не представляю, как сделать пример :(

 Отправлено: 09.08.11 16:11. Заголовок: Я с такой ситуацией ..

Я с такой ситуацией не сталкивался, потому лучше сразу в Harbour dev list думаю будет быстрее.

 Отправлено: 10.08.11 08:28. Заголовок: Нашел, где собака по..

Нашел, где собака порылась
Если в каком-то модуле присутствует строка:

#include "hbver.h"

то в модулях, которые компилируются после него, __HARBOUR__ не определен.

По-видимому, этот баг возникает, если компилятору harbour.exe задать компиляцию сразу нескольких модулей
Если их компилировать по отдельности, то все в порядке

Написал в devlist

 Отправлено: 10.08.11 10:37. Заголовок: У меня, кстати, тоже..

У меня, кстати, тоже уже бразильцы проявились с сообщением, что не могут собрать простой пример с frh.

Попробовал, и смог собрать только с harbour-30-bcc.lib, без нее идет ошибка про WsAIoctl() (?). Ниже мой ответ бразильцу с текстом bat-ника.

--
Hello, Julian,

> I have problem when compiling fastreport demo with harbour 3:
> Hbmk2 smpldemo fastreph

I downloaded Harbour3 and I can compile smpldemo. My bat-file
bellow. Firstly rename CurDrive() to hb_CurDrive() in smpldemo.

I compiled smpldemo with harbour-30-bcc.lib, without it some
problems with WsAIoctl() but it seems bug in Harbour3, of course not
in FRH. And it seems it's one of reason why Hbmk2 does not work
correctly.

----
@ECHO ON

@set HB_BIN_INSTALL=D:\hb30\bin
@set HB_LIB_INSTALL=D:\hb30\lib\win\bcc
@set HB_INC_INSTALL=D:\hb30\include

del FastDemo.c
del FastRepH.c

%HB_BIN_INSTALL%\harbour SmplDemo.prg -n -i%HB_INC_INSTALL%
%HB_BIN_INSTALL%\harbour FastRepH.prg -n -i%HB_INC_INSTALL%

bcc32 -O2 -d -X -I%HB_INC_INSTALL% -L%HB_LIB_INSTALL% SmplDemo.c FastRepH.c harbour-30-bcc.lib hbvm.lib hbrtl.lib
hbrdd.lib hbmacro.lib hbpp.lib rddntx.lib rddcdx.lib rddfpt.lib hbcommon.lib gtwin.lib hblang.lib hbcpage.lib hbct.lib
hbpcre.lib hbsix.lib hbzlib.lib hbextern.lib hbhsx.lib rddnsx.lib

---
Spirin Sergey.
"Paritet Soft" Company.
FRH sales: http://www.paritetsoft.ru/frh.htm
FRAX sales: http://www.paritetsoft.ru/frax.htm

 Отправлено: 10.08.11 10:51. Заголовок: Вроде бы ничего особ..

Вроде бы ничего особенного в этой функции нет
А что за ошибка ? Unresolved external ? Либа соответствующая указана ?

 Отправлено: 10.08.11 11:38. Заголовок: Имхо, в BCC в либе w..

Имхо, в BCC в либе ws2_32.lib имеется эта функция. Видимо, Harbour 3.0 сам ее подтягивает.

 Отправлено: 10.08.11 11:44. Заголовок: Pasha пишет: А что ..

Pasha пишет:

цитата:

А что за ошибка ? Unresolved external ?

Да:

Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
Error: Unresolved external 'WSAIoctl' referenced from D:\HB30\LIB\WIN\BCC\HBRTL.LIB|hbsocket

Pasha пишет:

цитата:

Либа соответствующая указана ?

Какая? Вроде обыскался, на вскидку не смог найти

 Отправлено: 10.08.11 11:45. Заголовок: ws2_32.lib..

ws2_32.lib

 Отправлено: 10.08.11 11:53. Заголовок: Сделал dll. Хочу сде..

Сделал dll. Хочу сделать соответствующую impoty library
Читаю help для hbmk2:

-hbimplib create import library

Задаю для hbmk2 соответствующую опцию

impoty library не создается.

Делаю ручками
Для bcc она делается с помощью implib, а как для mingw ?

Выдаю команду

if exist hbcontrib.dll dlltool -D hbcontrib.dll -l hbcontrib.lib

Либа создается нулевой длины и с лаконичным сообщением:

dlltool: CreateProcess

Как победить ? Хотелось бы прежде всего пнуть hbmk2

 Отправлено: 10.08.11 11:56. Заголовок: PSP пишет: Имхо, в ..

PSP пишет:

цитата:

Имхо, в BCC в либе ws2_32.lib имеется эта функция.

Вау! Добавил ws2_32.lib и действительно скомпилилось Да, про борландовские либы я и не подумал, искал в харбурных...

Интересно, что же в моем примитивном примере такого, что цепляется аж сокетное WinAPI?

http://www.paritetsoft.ru/downloads/frh_demo_simple_console.zip

 Отправлено: 11.08.11 00:44. Заголовок: Sergey Spirin пишет:..

Sergey Spirin пишет:

цитата:

Интересно, что же в моем примитивном примере такого, что цепляется аж сокетное WinAPI?

И размер exe вырос с 1.5 до 2.5 мегабайт.... На совсем почти голом приложении... Зачем все пихать в rtl?

Как-то все это настораживает... В особенности, уровень профессионализма исполнителей...

 Отправлено: 11.08.11 08:12. Заголовок: Sergey Spirin пишет:..

Sergey Spirin пишет:

цитата:

Интересно, что же в моем примитивном примере такого, что цепляется аж сокетное WinAPI?

Все файловые функции харбора допускают работу с файлами в памяти (префикс "mem:") и по сети через netio сервер (префикс "net:"). Эти же средства поддерживаются всеми стандартными rdd*. Для доступа через net: и необходимо сокетное api.
В стандартной сборке эти средства включены. При желании можно собрать харбор и без них.
Все это появилось в харборе уже 2 года как.

 Отправлено: 11.08.11 15:01. Заголовок: Sergey Spirin пишет:..

Sergey Spirin пишет:

цитата:

И размер exe вырос с 1.5 до 2.5 мегабайт.... На совсем почти голом приложении... Зачем все пихать в rtl? Как-то все это настораживает... В особенности, уровень профессионализма исполнителей...

? Hello, world

собранный Harbour 2.0 (2009 год), имеет размер 620К, а собранный Harbour 3.0 - на 15К больше. Так что с профессионализмом разработчиков все в порядке. Более того. Я смотрю, у нынешней версии Harbour по сравнению с xHarbour скорость выполнения операций rdd выше примерно на 30%. Так что не беспокойтесь, профессионализм высокий.

 Отправлено: 11.08.11 22:04. Заголовок: Pasha пишет: ? Hell..

Pasha пишет:

цитата:

? Hello, world

Угу, Паш, на меньшем ты проверить не мог? На самом примитивном демо, ссылку на которое ты можешь увидеть выше:

Harbour 0.97 - 1.1. MB
xHarbour 1.2.1 - 1.5 MB
Harbour 3 - 2,5 MB

Прости, но профессиональным это я назвать не могу.... BCC тот же ... Сокет открываем? Паш, сорри, ты умничка, но здесь сильно не прав.

 Отправлено: 11.08.11 22:24. Заголовок: Sergey Spirin пишет:..

Sergey Spirin пишет:

цитата:

Как-то все это настораживает... В особенности, уровень профессионализма исполнителей...

Предлагаю сразу в Harbour dev list оспаривать уровень а то попахивает холиваром. Читаем еще раз
Pasha пишет:

цитата:

В стандартной сборке эти средства включены. При желании можно собрать харбор и без них.

 Отправлено: 11.08.11 23:12. Заголовок: Вообще то мне тоже н..

Вообще то мне тоже не нравиться сильное увеличение размера ЕХЕ-ников.
Я собирал свою демку для Fast'a:
FastDemo_gtwin_ru.exe - 417280 24.01.08
FastDemo_gtwin.exe - 2501 К 11.08.11

AlexMyr пишет:

цитата:

Предлагаю сразу в Harbour dev list оспаривать уровень

Присоединяюсь.

 Отправлено: 12.08.11 00:25. Заголовок: Sergey Spirin пишет:..

Sergey Spirin пишет:

цитата:

Pasha пишет: цитата: ? Hello, world Угу, Паш, на меньшем ты проверить не мог? На самом примитивном демо, ссылку на которое ты можешь увидеть выше: Harbour 0.97 - 1.1. MB xHarbour 1.2.1 - 1.5 MB Harbour 3 - 2,5 MB Прости, но профессиональным это я назвать не могу.... BCC тот же ... Сокет открываем? Паш, сорри, ты умничка, но здесь сильно не прав.

Порылся в Harbour mailing list (Developers List) и нашел сообщение Przemek от 29 июля, тема Harbour evolution and WebServices, даю цитату:

Please read more carefully my messages. I know that my English is
fatal but if I aks you to strip final binaries then please do that.
Above result is size of standard unstripped harbour build.
Here are results for 32bit MinGW build (GCC4.6):

2011-05-07 13:33 147 hello.prg
2011-07-28 23:37 1˙136˙693 hello-32-std.exe
2011-07-29 00:28 1˙126˙171 hello-32-std-gc0.exe
2011-07-29 00:50 863˙284 hello-32-std-gc0-Os.exe
2011-07-28 23:37 863˙744 hello-32-strip.exe
2011-07-29 00:28 852˙992 hello-32-strip-gc0.exe
2011-07-29 00:51 585˙728 hello-32-strip-gc0-Os.exe

So your results suggests that you used standard Harbour build and you
created unstripped binaries and we are again at the beginning of this
discussion.
So please start your tests from -strip hbmk2 command and try:
hbmk2 hello.prg -strip
and check the size of hellow.exe. As you can see above it should be
close to 863˙744 bytes (hello-32-strip.exe) - some small diffeences
can appear du to different MinGW/GCC distributions.
Then you can try to rebuild Harbour with switches I was talking about.
In hello.prg -gc0 does not give significant size reduction because only
small part of HBRTL is linked with this code.

> I then built the xHarbout\tests\hello.prg (exactly same as
> above)). Size: 800,768 bytes

Not exactly if you have such results.
I've just downloaded current xHarbour and created new xHarbour MinGW
binaries. I had to set:
SET C_USR=-O3
because in xHarbour GNU make build system it's not enabled by default.
Here are results:
2011-07-29 01:15 1˙251˙503 hello-xhb-std.exe
2011-07-29 01:15 1˙026˙048 hello-xhb-strip.exe

I'm very interested how you are creating your xHarbour binaries and which
MinGW version you are using because still xHarbour binaries are bigger
when the same C compiler with the same switches is used and nothing
has changed here in last 8 years.

Я понимаю, что нет времени изучать все и вся, да никто и не заставляет этого делать, но если решитесь пообщаться в harbour dev list, то будет интересно понаблюдать и почитать.

 Отправлено: 12.08.11 11:38. Заголовок: AlexMyr пишет: Пред..

AlexMyr пишет:

цитата:

Предлагаю сразу в Harbour dev list оспаривать уровень а то попахивает холиваром.

Для харборов я человек сторонний, поэтому каким-то тщательным анализом заниматься, пересобирать харборы, конечно, не буду. То, что я сказал, это всего лишь эмоциональная оценка ситуации, основывающаяся на опыте и здравом смысле. За мегабайтом native-кода должен либо стоять сверхсерьёзный функционал, либо это бессмысленное цепляние библиотек, то есть проблемы с архитектурой.

 Отправлено: 12.08.11 12:28. Заголовок: Sergey Spirin пишет:..

Sergey Spirin пишет:

цитата:

пересобирать харборы, конечно, не буду

А я пересобрал Харбор, добавив в скрипт сборки только одну строку:
set HB_USER_PRGFLAGS=-gc0

При этом размер run-time RTL библиотеки для BCC уменьшился с 1.9 MБ до 1.1 МБ

Соответственно уменьшился и размер экзешников...

Для справки: этот Харбор будет доступен в следующей сборке библиотеки минигуи