Форум » [x]Harbour » hbmk2 » Ответить

hbmk2

Pasha: Как задать сборку библиотеки, если сырцы находятся в разных каталогах ? Причем в файле hbp не хотелось бы указывать абсолютный путь Хотелось бы задать переменные окружения: set HB_CT=\harbour\contrib\hbct\ set HB_WIN=\harbour\contrib\hbwin\ и затем их использовать в *.hbp, что-то вроде: $(HB_CT)addascii.c ... $(HB_WIN)axcore.c

Ответов - 36, стр: 1 2 All

AlexMyr: Как вариант в каждом каталоге создать 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 и все нормально.

Pasha: Столкнулся с какой-то совершенно бредовой ситуацией Использую релиз Harbour 3.0 С помощью hbmk2 собираю свою либу, в которой более сотни модулей. В этих модулях (prg) часто встречаются конструкции вида: #ifdef __HARBOUR__ ... #endif #ifndef __HARBOUR__ ... #else ... #endif Заметил, что многие модули были скомпилированы, как будто __HARBOUR__ не определен. Поставил флажок -p, посмотрел ppo - действительно так. Причем первые несколько модулей собираются с __HARBOUR__ а начиная где-то с 9-го - без. Если я правлю 9-й модуль, и запускаю hbmk2, то перекомпилируется только он один, и с уже определенным __HARBOUR__ Даже не представляю, как сделать пример :(

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


Pasha: Нашел, где собака порылась Если в каком-то модуле присутствует строка: #include "hbver.h" то в модулях, которые компилируются после него, __HARBOUR__ не определен. По-видимому, этот баг возникает, если компилятору harbour.exe задать компиляцию сразу нескольких модулей Если их компилировать по отдельности, то все в порядке Написал в devlist

Sergey Spirin: У меня, кстати, тоже уже бразильцы проявились с сообщением, что не могут собрать простой пример с 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

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

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

Sergey Spirin: 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 пишет: Либа соответствующая указана ? Какая? Вроде обыскался, на вскидку не смог найти

Pasha: ws2_32.lib

Pasha: Сделал 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

Sergey Spirin: PSP пишет: Имхо, в BCC в либе ws2_32.lib имеется эта функция. Вау! Добавил ws2_32.lib и действительно скомпилилось Да, про борландовские либы я и не подумал, искал в харбурных... Интересно, что же в моем примитивном примере такого, что цепляется аж сокетное WinAPI? http://www.paritetsoft.ru/downloads/frh_demo_simple_console.zip

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

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

Pasha: Sergey Spirin пишет: И размер exe вырос с 1.5 до 2.5 мегабайт.... На совсем почти голом приложении... Зачем все пихать в rtl? Как-то все это настораживает... В особенности, уровень профессионализма исполнителей... ? Hello, world собранный Harbour 2.0 (2009 год), имеет размер 620К, а собранный Harbour 3.0 - на 15К больше. Так что с профессионализмом разработчиков все в порядке. Более того. Я смотрю, у нынешней версии Harbour по сравнению с xHarbour скорость выполнения операций rdd выше примерно на 30%. Так что не беспокойтесь, профессионализм высокий.

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

AlexMyr: Sergey Spirin пишет: Как-то все это настораживает... В особенности, уровень профессионализма исполнителей... Предлагаю сразу в Harbour dev list оспаривать уровень а то попахивает холиваром. Читаем еще раз Pasha пишет: В стандартной сборке эти средства включены. При желании можно собрать харбор и без них.

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

AlexMyr: 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, то будет интересно понаблюдать и почитать.

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

gfilatov2002: Sergey Spirin пишет: пересобирать харборы, конечно, не буду А я пересобрал Харбор, добавив в скрипт сборки только одну строку: set HB_USER_PRGFLAGS=-gc0 При этом размер run-time RTL библиотеки для BCC уменьшился с 1.9 MБ до 1.1 МБ Соответственно уменьшился и размер экзешников... Для справки: этот Харбор будет доступен в следующей сборке библиотеки минигуи



полная версия страницы