Ru-Board.club
← Вернуться в раздел «Тестирование»

» SciTE Ru-Board Edition

Автор: vladvro
Дата сообщения: 15.09.2008 11:08
alrusdi81

Цитата:
Пустое значение возвращает.

ага, теперь вижу - двойное объявление переменной:
SciTEGTK.cxx [строка 537] :
Код: static SciTEGTK *instance;
Автор: alrusdi81
Дата сообщения: 16.09.2008 08:17
vladvro
Сейчас переменная instance является членом класса и это хорошо. Но почему то не работает, пустая она все время. Не зря ведь Нейл написал TODO по этому файлу.
Я сейчас для отладки объявляю переменную globinstance в глобальной области видимости, беда такого подхода в том, что если будет создано несколько объектов класса SciTEGTK то эта переменная будет содержать только последний из созданных экземпляров. И вообще глобальные переменные зло. Правда лучшего решения я пока не вижу.
Еще смущает следующее: instance - это указатель на переменную типа SciTEGTK, а метод
SciTEBase *SciTEBase::GetApplicationInstance()
возвращает тип SciTEBase. Это нормально?
Автор: vladvro
Дата сообщения: 16.09.2008 11:04
alrusdi81

Цитата:
Сейчас переменная instance является членом класса и это хорошо. Но почему то не работает, пустая она все время. Не зря ведь Нейл в этом файле написал TODO по этому файлу.

Странно что пустая... а если 563 строку закомментировать?

Цитата:
Я сейчас для отладки объявляю переменную globinstance в глобалной области видимости, беда такого подхода в том, что если будет создано несколько объектов класса SciTEGTK то эта переменная будет содержать только последний из созданных экземпляров.

static переменная класса - это и есть глобальная переменная, только с ограничением области видимости. И в ней тоже будет храниться только последний экземпляр класса. Но нас это устраивает, т.к. больше одного экземляра создавать не предполагается.

Цитата:
Еще смущает следующее: instance - это указатель на переменную типа SciTEGTK, а метод
SciTEBase *SciTEBase::GetApplicationInstance()
возвращает тип SciTEBase. Это нормально?

все нормально, он возвращает указатель на наследника класса.
Автор: BioInfo
Дата сообщения: 17.09.2008 12:09

Цитата:


Код: void Add(const char * label = 0, int cmd = 0, int enabled = 1, const char *mnemonic = 0, int position = -1);

поменять на:

Код: void Add(const char * label ="", int cmd = 0, int enabled = 1, const char *mnemonic = "", int position = -1);
Автор: alrusdi81
Дата сообщения: 18.09.2008 10:19
Да, можно и так.
Автор: mozers
Дата сообщения: 18.09.2008 11:25
Уважаемые, может быть давайте закончим войну библиотек???

Стив Донован, тот самый который придумал как адаптировать внешние Lua библиотеки для SciTE использует для этого дела файл SciTE.lib.

BioInfo (так же уважаемый нами автор) почему то решил использовать scite.la. Он использовал этот файл при компиляции shell.dll а сейчас добавил его в Доновановский дистрибутив gui.dll.

UR4LTZ (молодой и перспективный творец) решил использовать libscite.a. который он использовал при компиляции winreg.dll, а чтобы в дальнейшем ни у кого проблем не возникало этот файл был добавлен в размещенный на сайте проекта дистрибутив MinGW-mini.

Ребята, мы вас всех очень уважаем, но давайте наконец определимся раз и навсегда какой из вариантов будем использовать!
Пихать в дистрибутив каждый свой вариант, при наличии авторского - не дело.
Автор: BioInfo
Дата сообщения: 18.09.2008 12:36
mozers
Свою позицию я высказал:
"Задача следующая - программер сливает из SVN сборку, нажимает build и у него все компилится без дополнительных телодвижений.
С какой такой радости я вручную должен себе какие то левые библиотеки пихать в MinGW?"
Как решит большенство так и будет, и я буду этого придерживаться.


Цитата:
Стив Донован ... использует для этого дела файл SciTE.lib.

Не совсем так. MinGW не понимает SciTE.lib, по этому я использую scite.la, как его получить писал Стив в скайте интерестс. На сколько ты помнишь за основу для shell была взята Донованская библиотека где как раз использован scite.la

Решение UR4LTZ имеет следующие недостатки:
1. Чтобы скомпилить SciTERu нужно для этого скачать специально подготовленный компилятор, к тому же изрядно покоцанный
Альтернативный вариант:
1. найти где нибудь файл libscite.a, скачать его
2. найти где у нас располагаются библиотеки MinGW
3. скопировать туда этот libscite.a где он будет лежать мертвым грузом (я ведь только тем и занимаюсь что создаю библиотеки для sciTE верно?

Если вы считаете это не существенным, то так и скажите.

Мое решение имеет следующие недостатки:
1. На каждую библиотеку для scite нужно иметь файлы scite.la и SciTE.lib
2. дописать по вкусу
Проблема 1 решается следующим способом - просто в корень lualib кинуть их и всего делов, от туда уже подключать.

По этому я предлагаю решение с использованием scite.la
Автор: vladvro
Дата сообщения: 18.09.2008 13:11
Поддерживаю BioInfo, дополнять MinGW СВОИМИ библиотеками - это в корне не верно.

Цитата:
Проблема 1 решается следующим способом - просто в корень lualib кинуть их и всего делов, от туда уже подключать.

вот это правильно.
а еще лучше добавить командный файл, который будет гененерить эту либу, если это не сложно.
Автор: BioInfo
Дата сообщения: 18.09.2008 13:50
vladvro
Генератор scite.la через батник есть в ревизии 544
SciTE.lib генерируется при сборке SciTE через студию
Автор: vladvro
Дата сообщения: 18.09.2008 14:39
BioInfo

Цитата:
Генератор scite.la через батник есть в ревизии 544

а почему потом изчез?

Цитата:
SciTE.lib генерируется при сборке SciTE через студию

а без студии нельзя?
Автор: mozers
Дата сообщения: 18.09.2008 16:17
Можно класть читабельный и редактируемый scite.def и из него генерить scite.la командой
dlltool -d scite.def -l scite.la
после компиляции scite.la удалять.

Остаются 2 вопроса:
1. Какое название более корректно scite.la или libscite.a ?
2. Как и из чего в ком.строке сгенерить SciTE.lib ? (И нужен ли он в этом ВООБЩЕ в этом случае???)
Без него, кстати, все компилится и работает!
Автор: UR4LTZ
Дата сообщения: 18.09.2008 16:39
vladvro
Цитата:

а без студии нельзя?


Можно! Вот как это можно и нужно делать!

pexports.exe scite.exe > scite.def
dlltool.exe -d scite.def -l libscite.a


mozers

Цитата:
1. Какое название более корректно scite.la или libscite.a ?

Если посмотреть в Mingw\lib то мы увидем файлы libxxxxx.a это стандарт.
А вот что касаться scite.la так это только от того что TortoiseSVN
игнорирует все файлы с расширением .a Я считаю что следует придерживаться стандарта и использовать libscite.a
Что касается SciTE.lib так это библиотека от VC и к MinGW не имеет отношения.

mozers

Цитата:
2. Как и из чего в ком.строке сгенерить SciTE.lib ?

Смотри ответ vladvro.
Автор: vladvro
Дата сообщения: 18.09.2008 17:09

Цитата:
1. Какое название более корректно scite.la или libscite.a ?

расширение явно должно быть .a, значит либо scite.a либо libscite.a

UR4LTZ

Цитата:
pexports.exe scite.exe > scite.def

а pexports.exe утилита из пакета MinGW ?
Автор: mozers
Дата сообщения: 18.09.2008 17:10
UR4LTZ
Цитата:
pexports.exe scite.exe > scite.def
Спасибо, буду знать
В даном случае, поскольку содержимое scite.def меняется крайне редко, имеет смысл класть его уже готовый (благо размер его - мизерный).
Автор: vladvro
Дата сообщения: 18.09.2008 17:21

Цитата:
А вот что касаться "scite.la" так это только от того что TortoiseSVN
игнорирует все файлы с расширением ".a"

впринципе принудительно добавить не проблема.
Автор: UR4LTZ
Дата сообщения: 18.09.2008 17:48

Цитата:
В даном случае, поскольку содержимое scite.def меняется крайне редко, имеет смысл класть его уже готовый (благо размер его - мизерный).

Я предлагаю в makefile вставить примерно вот такой кусочек.
Смысл такой если libscite.a не найдена то она будет заново создана.
И держать scite.def не нужно. Можно его оформить отдельно и включать во все makefile по
#include.


Код: LUALIB=libscite.a

xxxxx.dll: $(LUALIB) xxxxx.o
g++ $(CFLAGS) -s -o xxxxx.dll xxxxx.o -l$(LUALIB)

$(LUALIB)
: ..\..\pack\SciTE.exe
pexports ..\..\pack\scite.exe > scite.def
dlltool -d scite.def -l libscite.a
Автор: vladvro
Дата сообщения: 18.09.2008 18:38

Цитата:
А лучше как это сделал я и mozers положить его в папку\lib\ и вставлять в makefile вот таким образом LIBS=-lscite -lgdi32

вставлять его таким образом я рад, а вот папочку \lib\ надо завести в проекте, и пусть MinGW берет эту либу от туда, полагаю это возможно.

Цитата:
Да. Только его нет в MinGW-Mini в CodeBlocks лежит в
C:\Program Files\CodeBlocks\MinGW\bin\ но правда весит 421к
после strip.exe --strip-all pexports.exe худеет до 20к

значит надо его добавить в пакет на сайте и лучше конечно в пожатом виде.
Автор: BioInfo
Дата сообщения: 18.09.2008 19:13
mozers

Цитата:
1. Какое название более корректно scite.la или libscite.a ?

Оба названия политкорректны и права малых народностей не ущемляют
Работает scite.la, зачем выдумывать всякие глупости? Абсолютно не важно как это называется. Называйте как хотите!

UR4LTZ

Цитата:
Компилятор если ему сказать -lscite уберет из имени libscite.a первые lib и будет нормально работать.

А если ему просто сказать scite.la - он его скушает без всяких премудростей и ухищрений
make.cmd [строка 31] :
Код: gcc -s -shared -o shell.dll -I%INC% shell.cpp resfile.o scite.la -lshlwapi -lstdc++
Автор: mozers
Дата сообщения: 18.09.2008 21:45
BioInfo
Цитата:
Тоже самое кстати касается файла def - не нужно никакой отдельной приблуды чтобы его получить! def, lib, a и прочее - это побочный эффект сборки
Компилил
Цитата:
генерация всех этих штук это безусловно прекрасно, но не проще просто эти два файла кинуть в каталог lualib и забыть про них?

в MinGW и в Microsoft Visual Studio .NET 2003 - SciTE.lib действительно образуется, но никакого файла .ref нет и в помине.

Цитата:
не проще просто эти два файла кинуть в каталог lualib и забыть про них?
Не забывайте что gui.dll - это самостоятельный продукт, а не одна из частей нашей неповторимой сборки!
Надо чтобы ее мог скомпилить любой чел у которого есть исходники SciTE (с lualib) и компилятор.
Поэтому, если MinGW не может использовать SciTE.lib (что то я сильно сомневаюсь в этом), и ей позарез нужно именно scite.la, то добавлять в пакет нужно было было не файл непонятного содержания под названием scite.la, а файл scite.def.

Цитата:
У mozers такая же хрень была - не учитывались пробелы и табы...
Виноват. Автоматом вставляю измененные Стивом строки с помощью CompareIt! (У него проблемы с подключением к нашему SVN).


Добавлено:
Только что откомпилил gui.dll в MinGW и в Microsoft Visual Studio .NET 2003 уничтожив все ваши libscite.a, scite.la, scite.def (оставил только родной SciTE.lib) - полет нормальный
Автор: BioInfo
Дата сообщения: 19.09.2008 19:00
Война окончена

Цитата:
Только что откомпилил gui.dll в MinGW и в Microsoft Visual Studio .NET 2003 уничтожив все ваши libscite.a, scite.la, scite.def (оставил только родной SciTE.lib)

Проблема решена для библиотек gui и shell.
Отстаивая свою точку был не прав. Не кидайте помидорами
Автор: cvaqlav
Дата сообщения: 19.09.2008 19:44
alrusdi81
Спасибо, конечно, на добром слове, только я в этом деле, как говорится, и палец о палец не ударил. ((
UR4LTZ
Спасибо, выручил.
All
А чего вы велосипед изобретали? Я же вас недавно попросил попинать свой вариант для сборки MinGw. Он как раз между делом берёт "студийный" scite.lib (тот, что получается после сборки SciTE), и конвертирует его в понятный линкеру, формат. Единственное путнее, что я сделал, никто не заметил. Или там, всё-таки, страшные косяки?
Автор: mozers
Дата сообщения: 19.09.2008 19:46
BioInfo
Да и не было никакой войны. Просто очень хотелось выяснить истину.
Для меня было большим откровением что SciTE.lib можно взять из "мусора" после компиляции SciTE.
Да и вообще прозвучало очень много новой инфы которую вы, программеры, скрываете от простого народа


Добавлено:
Нет, ребята, все оказывается не так просто
Последний (он же самый первый - Доновановский - с Scite.lib) вариант компиляции отрабатывает с MinGW-mini без единой ошибки и предупреждения.
Но приготовленная с его помощью gui.dll при первом же запуске валит редактор
Не спешите переделывать опять все взад! (лишь бы работало).
Объясните ПОЧЕМУ Доновановский вариант не работает???
Автор: BioInfo
Дата сообщения: 20.09.2008 00:32
mozers

Цитата:
Но приготовленная с его помощью gui.dll при первом же запуске валит редактор

Вспомнил почему я делал эти заморочки co scite.la По этой самой причине...
Можно как нить отменить ревизию? 748

Цитата:
Объясните ПОЧЕМУ Доновановский вариант не работает???

Потому как scite.lib не в том формате, для minGW нужно собирать библиотеку в понятном для него виде, как это сделать из def файла писал Стив Донован в группе буржуйской по скайте. То что он сюда вставил не так как сам же делал до этого, дык думаю он просто напарил, наверняка как я со студией работает только, а minGW поддерживает постольку поскольку и забыл про такую оказию.
Точно как я, собрал когда то давно scite.la, использовал ее по принципу - работает не трогай, все работало благополучно, что за траблы сподвигли ее сделать забыл... А потом пришли и сказали: ну ты, браток, делаешь не так как белые люди...
cvaqlav

Цитата:
Я же вас недавно попросил попинать свой вариант для сборки MinGw. Он как раз между делом берёт "студийный" scite.lib (тот, что получается после сборки SciTE), и конвертирует его в понятный линкеру, формат

Запости, пожалуйста, батники сюда на форум целиком. Можно даже SciTE для этого использовать, там есть пункт - преобразовать код для публикации на форуме.
Автор: vladvro
Дата сообщения: 20.09.2008 09:46
BioInfo

Цитата:
Можно как нить отменить ревизию?

да, например с помощью TortoiseSVN делается так:
- открываешь историю изменений (show log)
- находишь нужную ревизию
- в контекстном меню выбираешь пункт отмены изменений этой ревизии (revert changes from this revision)
- после этого комитишь новую версию
Автор: cvaqlav
Дата сообщения: 20.09.2008 10:36
BioInfo

Цитата:
Запости, пожалуйста, батники сюда на форум целиком.

Вот же... Битый час искал нормальный файл-хостинг, без мультиков и капчи... Казалось, нашёл. А сейчас он мне фигу показывает. Теперь понятно. Большое сорри всем.
make_mingw.cmd :
[more]
Код:
@echo off

rem -----------------------------------------------------------------
rem Path to MinGW
rem set MINGW=%mingw_mini%

set MINGW=c:\MinGW\bin

rem Path to root folder with SciTE sources
set SCITE_ROOT=..\..\src

rem -----------------------------------------------------------------
set PATH=%MINGW%;%PATH%

rem ------- build gui.dll -------------------------------------------
mingw32-make -f mingw.mak
rem ------- build ngui.dll ------------------------------------------
mingw32-make -f mingw.mak NO_WINDOW_SUBCLASS=1

rem ------- rebuild gui.dll -----------------------------------------
rem mingw32-make -f mingw.mak rebuild
rem ------- rebuild ngui.dll ----------------------------------------
rem mingw32-make -f mingw.mak rebuild NO_WINDOW_SUBCLASS=1

pause
Автор: mozers
Дата сообщения: 21.09.2008 13:55
ALL
Что то голова (и SVN) уже пухнет от многочисленных вариантов компиляции Lua-библиотек.

Слава потомков достанется тому, кто придумает универсальный вариант, подходящий и для MinGW и для Студии.
Вариант, который будет сам на лету генерить эти вспомогательные SciTE.lib, scite.la, libscite.a из единственного текстового файла (типа scite.def).

Создавать scite.def "на лету" не нужно.
Во-первых - появляется нехорошая внешняя привязка к scite.exe.
Во-вторых - нефиг постоянно генерить одно и то же (содержимое то - постоянно).
В-третьих - можно и нужно внутрь этого файла добавить комментарий в котором описать как его получить (так как это сделано во многих файлах исходников scite).
Автор: UR4LTZ
Дата сообщения: 23.09.2008 00:55
Заметил интересную фишку после включения оптимизации при сборке shell.dll.

Оптимизация отключена.

Цитата:

File size Ratio Format Name
-------------------- ------ ----------- -----------
40448 -> 16896 41.77% win32/pe shell.dll


Оптимизация включена "-Os".

Цитата:

File size Ratio Format Name
-------------------- ------ ----------- -----------
38912 -> 17408 44.74% win32/pe shell.dll


Ясно видно что размер файла стал меньше но после упаковки UPX мы не выиграли а проиграли в размере.
Автор: frs
Дата сообщения: 25.09.2008 18:17
Почти ничего не понимаю в *.cmd и make файлах, поэтому у меня огромная просьба, чтобы кто-нибудь написал мне *.cmd и make работающие следующим образом для mingw
1) cmd1 - компилирует всё как обычно, но не удаляет за собой никакого сгенерированного промежуточного мусора, типа объектных файлов
опционально составляет список исходных файлов с их датой
2) cmd/make2 - проверяет все файлы по списку на изменение даты, и если она поменялась, то компилирует объектный файл только для данного файла, затем из оставшихся от cmd1 файлов и вновь сгенерённых файлов для изменившегося кода собираются необходимые exe-dll и т.п. При отсутствии списка или старых-объектных файлов запустит cmd1
3) Ну и при желании я смогу перекомпилировать/почистить всё старым make.cmd

Я просто замучился ждать перекомпиляции после правки каждой мелочи. Или поскажите мне другой workflow, для ускорения процесса.
Автор: UR4LTZ
Дата сообщения: 25.09.2008 20:48
frs:

Думаю помогу с makefile. Стучи в контакт ниже.

jabber: ur4ltz@jabber.ru
Автор: vladvro
Дата сообщения: 25.09.2008 23:18
frs

Цитата:
Я просто замучился ждать перекомпиляции после правки каждой мелочи. Или поскажите мне другой workflow, для ускорения процесса.

запускай make.cmd с опцией /build

Страницы: 1234567891011121314151617181920212223242526

Предыдущая тема: test


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.