destiny child
Silver Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
yozhic (пост)
Цитата:| Всё ж работало и так, поэтому и в голову не приходило. И если б Вы внимание не обратили, то |
мы бы не узнали, что ошибка на стороне сборщика)))
кто там собирал и выкладывал этот последний 4416 билд?
ладно - эт не ошибка, конечно же, но нюанс, о котором может и не знать каждый.
(P.S. если только в коде проекта всё ТАААААК своеобразно исходным разрабом не наверчено, что и далее описанные шаги не приведут к пользе и ожидаемому толку)
Так вот дело в том, что в коде работа с папкой Plugs или Plugs64 заперта под директивой условной компиляции:
#ifdef _WIN64
....
#else
.......
#endif
И вот корень зла кроется в том факте, что если собирать проект просто в VS студии, просто выбрав платформу х64 в комбобоксе панели сборки - то этим самым вы не включите этот флаг препроцессора для его работы в местах его внедрения!
Да-да, угу-угу. Майкрософтцы совсем заплутали в 3 соснах и переложили на плечи разраба ответственность в том, чтоб понимать КАК надо собирать ИСТИННУЮ реальную 64 битную прогу. Поэтому нам надо РУКАМИ! добавить флаги 64 битности по пути:
Тут для примера сборка плагина - где я собирал лишь 64 релиз - поэтому на картинке лишь это сочетание. В принципе и на дебаг надо так же вставить изменения, но это, имхо, что для плагина, что для самого AkelPad'a будет лишним - т.к. мы тут ни разу дебаг версию собирать/юзать не планируем))
И это же исправление надо, кстати, делать и для файла ресурсов! *.RC который. По идее там должно идти наследование от свойств проекта. Но иногда оно ломается и тогда логичнее конкретно для файла выставить:
тут у меня правда наследование сработало - видно, что значения не жирным шрифтом описаны.
Но проверять всегда это важно. Ибо внутри файла ресурсов может быть написано так:
Код: #ifdef _WIN64
VALUE "ProductName", "SpellCheck (x64)"
#else
VALUE "ProductName", "SpellCheck (x86)"
#endif
|
т.е. в информации о файле, когда мы будем смотреть итоговый dll - мы должны увидеть разный текст, в зависимости от того - под какую платформу мы собрали либу/ехе.
P.S. Еще вариант, чтобы сделать корректнее - если унаследование флагов для ресурсов почему-то не прошли автоматом, то открыть в текстовом редакторе файл vcxproj и прям перед закрывающим тегом </ItemDefinitionGroup> для нужной конфигурации, к примеру сейчас это: <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'"> вставить вот этот код:
Код:
<ResourceCompile>
<PreprocessorDefinitions>_WIN64;_AMD64;%(PreprocessorDefinitions)</PreprocessorDefinitions>
</ResourceCompile>
|
Я попробовал сейчас исходники 4416 сабжа собрать - просто предварительно, чтоб понять - что могу собирать - но что-то у меня ошибки попёрли.... Это без каких-то еще изменений. Просто скачал - запустил. Так что этот путь пересборки лучше бы пройти тому, кто УЖЕ точно собирал этот билд. Надо просто выставить нужные флаги препроцессора и всё тогда после сборки будет шикарно по умолчанию!
А вот сохранение всей мишуры, поиск каких-то стартовых файлов/ресурсов у плагинов построен реально на умолчательном пути до <AkelPadDir>\AkelFiles\Plugs\SpellCheck
Т.е. даже если мы запускаем 64 битный сабж, а он строит пути и грузит чистые 64 битные плагины, то при запуске любого из них - свои настройки/первичные загрузки чего-либо плаг сделает по этому 32 битному пути. НО этот момент уже не страшен. Это можно и использовать как есть. Главное - это пересобрать 64 битный сабж с нужными флагами, чтобы он по умолчанию генерил пути до 64 битной папки плагинов!
Добавлено:
Кстати - я пересобрал dll плагина еще раз - включив оптимизацию скорости. Не особо заметно правда, чтобы что-то изменилось в итоговом файле, но факт есть факт. Новая ссылка:
https://www.upload.ee/files/15260466/SpellCheck.7z.html
старую убил. |
AkelPad 
