[nickname2019]

На мой взгляд, основными проблемами российского рынка расчетного программного обеспечения являются:
- отсутствие нормальной возможности программной автоматизации по решению расчетных задач
(в расчетных программах отсутствует возможность для нормального программирования, т.е. невозможно написать программу для полностью автоматического создания расчетной схемы (нескольких расчетных схем), автоматического выполнения расчета, автоматического получения результатов и их автоматического анализа);
- закрытый исходный код по подбору расчетных параметров несущих элементов
(различные программы дают различные результаты при решении одинаковых задач, сравнение алгоритмов подбора различных между собой невозможно, так как код закрыт, общепринятых и одобренных алгоритмов нет, каждый пользуется своим "черным ящиком", который иногда может выдать ошибочное решение);
- для людей, которые занимаются автоматизацией на Лисп, C# и т.д. отсутствуют инструменты, которые позволяли бы программно "по-простому" вызвать готовую библиотечную функцию (например, по подбору сечения какой-то простой балки непосредственно из графического редактора), что вызывает необходимость вызова отдельной расчетной программы, что серьезно тормозит работу;
- "корявый" интерфейс, ужасно неудобная и медленная работа в существующих российских (и украинских) расчетных программах;
(фактически при наличии нормального графического редактора (autocad, nanocad и т.д.) приходится экспортировать данные в в "корявый" редактор расчетной программы и длительное в нем работать (задавать нагрузки, связи и т.д.), а встроить расчетную программу в нормальный графический редактор через автоматизацию невозможно).

В связи с вышеизложенным, назрел вопрос:
Как технологически наиболее правильно можно организовать разработку расчетного программного обеспечения с открытым исходным кодом?

Для совместной разработки кода создано общее хранилище на GitHub, используя которое каждый может поучаствовать в разработке :
https://github.com/chaosEagleOwl/source

На данным момент работа находится в стадии тестирования возможности совместной разработки.
Требования к программному обеспечению изложены в файле (ссылка README.md на GitHub): https://github.com/chaosEagleOwl/source/README.md

ТЗ на модуль формирования КЭ-сеток сформировано и помещено на GitHub.
На весь комплекс ТЗ формировать долго, видимо, будет чуть позже.

Сформирована доска для управления проектом, туда добавлены наиболее актуальные задачи.
Задачи проекта.

[nickname2019]

Создал тестовый проект:
https://github.com/chaosEagleOwl/source

Проект создан пока для тестирования возможности совместной разработки.
В проекте прописаны пути из учета, что Visual Studio 2019 установлена на диске C:

Чтобы не думать о том, как назвать проект, название принято по умолчанию- ArxProject1.

В проекте три каталога:
VS2019(c++)ac2021- проект для Visual Studio 2019 и Acad 2021
ArxLib - библиотеки arx.
common - это для общих модулей в случае, если будут компилироваться исполняемые arx для других версий графического редактора.

Чтобы не возникали проблемы с локальными путями
локальный репозиторий думаю лучше хранить как
C:\GitHub\

Таким образом, после синхронизации с GitHub, локальный путь к проекту должен быть
C:\GitHub\source\VS2019(c++)ac2021\ArxProject1\ArxProject1.sln

До начала работы, думаю, следует установит ObjectARXWizard

Путь для запуска установки (после синхронизации):
C:\GitHub\source\ArxLib\ObjectARX_for_AutoCAD_2021_Win_64bit_dlm\ObjectARXWizard2021.msi

После запуска установки в качестве пути для SDK следует указать:
C:\GitHub\source\ArxLib\ObjectARX_for_AutoCAD_2021_Win_64bit_dlm\
(если указать другой путь - наверняка не найдет библиотеки при компиляции)

Для возможности отладки командой _appload в список автозагрузки Autocad должен быть добавлен файл:
C:\GitHub\source\VS2019(c++)ac2021\ArxProject1\x64\Debug\ArxProject1.arx

Для тестирования реализована только команда (из командной строки) -
MYHELLO
которая приветствует мир.

Желающим присоединиться к проекту можно пробовать устанавливать GitHub и тестировать возможности запуска и компиляции.

Можно также посмотреть настройки проекта, покритиковать, может что-то поправить надо.

[trir]

почитай про gitignore - Debug'у в репозитории не место
для примера https://github.com/triroakenshield/R...ter/.gitignore

[nickname2019]

Сообщение от trir почитай про gitignore - Debug'у в репозитории не место для примера https://github.com/triroakenshield/R...ter/.gitignore

Спасибо. Я первый раз столкнулся с репозиторием. Самые большие файлы исключил, про debug "в целом" не догадался.
Поправлю.
Также добавил библиотеки objectarx в полном составе. Это, наверно, не самая удачная идея, но это должно обеспечить совместимость путей + простое обновление в случае, если библиотека поменяется.

[Кулик Алексей aka kpblc]

А в проекты на плюсах NuGet пакеты не подтягиваются, что ли?

[trir]

А в проекты на плюсах NuGet пакеты не подтягиваются, что ли?

ObjectArx можно скачать только с сайта доски

[nickname2019]

Если кто хочет участвовать - подключайтесь к редактированию (заодно можно с c++ разобраться, кто не знает).
Там как-то запрос на GitHube делать вроде надо.

[trir]

можно из VS изменения сразу на GitHub отправлять

[nickname2019]

Если возникают проблемы с компиляцией - прошу сообщать.

[румата]

Сообщение от Кулик Алексей aka kpblc А в проекты на плюсах NuGet пакеты не подтягиваются, что ли?

Крнечно нет. В том числе и поэтому я был против плюсов для автокада

[nickname2019]

Сообщение от румата Крнечно нет. В том числе и поэтому я был против плюсов для автокада

Я просто не работал с #Net.

Планируется:
на objectarx будет писаться только интерфейсная часть (взаимодействие с граф. редактором), а расчетные процедуры могут быть запакованы в *.dll и подключены к #Net. На c++ оказывается проще брать и модифицировать сторонний исходный код (в основном математика написана на c++).
Кроме того, отдельные модули можно писать на #Net, если кому-то так удобнее.

Если кто-то желает создать интерфейсную часть на #Net, я не против. Код можно писать параллельно.
Нужно создать второй каталог и в нем решение на #Net. Потом гитхабом синхронизируем с основным каталогом. На #Net я не смогу эффективно писать.

Если кто-то желает создать проект на других языках - также можно создать другой каталог и в нем работать.

[trir]

под NET API можно и на плюсах писать

[nickname2019]

Сообщение от trir под NET API можно и на плюсах писать

При создании проекта я не включил поддержку #Net и не включил поддержку COM.

Думаете, нужно пересоздать решение и включить поддержку Net и COM?
(в настройках проекта наверно будет очень трудно это поменять).

Пока, наверное, оставлю как есть.

[trir]

можно сделать отдельные проекты

[Сергей812]

Техзадание опосля напишите?

[румата]

Сообщение от trir под NET API можно и на плюсах писать

Можно, но тем, кто привык к написанию в нативном си(пусть даже с плюсами) такое написание будет ударом "по дых"

[Нубий-IV]

Сообщение от nickname2019 Если возникают проблемы с компиляцией

Может, это просто кривые руки... Я сижу под бесплатным пятым нанокадом, и автокадовская версия мне не интересна. Я проверил возможность собрать это все под нанокад в двух версиях студии. В обоих случаях до моего кода дело не доходит - сотня ошибок набирается прямо в SDK, и компиляция останавливается.

VS 2019 Community не желает собирать даже пустой проект (в котором есть только точка входа в dll и ничего больше) - идет сплошная ругань на SDK-шные заголовки (они предназначены в оригинале для VS 2008). Например, "fabs не найдена в пространстве имен std". Если по советам из гугла сделать "std { #include <stdlib> }", то появляется противоположное требование - "operator new не может быть переопределен в std". И таких сообщений там сотни.

VS 2008 Express до сих пор доступна для скачивания с сайта Microsoft. И пустая DLL под автокад, с заголовками из ObjectARX 2011, в ней собирается без проблем. Но для нанокада опять фокусы с заголовками SDK - как минимум в одном из них классы определяются с использованием CStringW; в других есть ссылки на "afxwin.h". Как я понимаю, это значит, что для сборки нужна VS 2008 Professional, с библиотеками ATL и MFC. Можно в opensource-проекте иметь ссылки на коммерческие библиотеки, которые сегодня, похоже, и купить уже нельзя?

[nickname2019]

Сообщение от Нубий-IV Может, это просто кривые руки... Я сижу под бесплатным пятым нанокадом, и автокадовская версия мне не интересна. Я проверил возможность собрать это все под нанокад в двух версиях студии. В обоих случаях до моего кода дело не доходит - сотня ошибок набирается прямо в SDK, и компиляция останавливается. VS 2019 Community не желает собирать даже пустой проект (в котором есть только точка входа в dll и ничего больше) - идет сплошная ругань на SDK-шные заголовки (они предназначены в оригинале для VS 2008). Например, "fabs не найдена в пространстве имен std". Если по советам из гугла сделать "std { #include <stdlib> }", то появляется противоположное требование - "operator new не может быть переопределен в std". И таких сообщений там сотни. VS 2008 Express до сих пор доступна для скачивания с сайта Microsoft. И пустая DLL под автокад, с заголовками из ObjectARX 2011, в ней собирается без проблем. Но для нанокада опять фокусы с заголовками SDK - как минимум в одном из них классы определяются с использованием CStringW; в других есть ссылки на "afxwin.h". Как я понимаю, это значит, что для сборки нужна VS 2008 Professional, с библиотеками ATL и MFC. Можно в opensource-проекте иметь ссылки на коммерческие библиотеки, которые сегодня, похоже, и купить уже нельзя?

Я думаю, что мы можем включать что угодно.
Мы пишем не бесплатное, а максимально открытое рабочее ПО.
Или мы напишем полностью открытое и бесплатное, но не рабочее ПО.
Nanocad раньше предоставлял бесплатную лицензию на Nanocad для разработчиков ПО (и SDK). Вы уверены, что нет смысла переходить на Nanocad более новой версии?
P.S.
Может проект перезамутить на Nanocad 10?

[Нубий-IV]

Сообщение от nickname2019 Может проект перезамутить на Nanocad 10?

Зачем? Все равно его надо собирать под разные версии. В моем наборе команд была папка с исходниками (одна-единственная, неизменная), и несколько файлов VS-2008.sln, VS-2012.sln, VS-2017.sln, VS-2018.sln, VS-2019.sln, в каждом из которых были свои настройки для акадов с 2005 по 2019, в каждом по несколько проектов, для всех поддерживаемых версий. Тут можно сделать так же, только еще и под нанокад настройки добавятся (теоретически они должны те же исходники переваривать, только я это еще не проверил, у меня студии не Pro).

Вот так оно должно выглядеть: "Портирование С++ приложений на платформу nanoCAD, использование страниц свойств проекта"

[nickname2019]

Сообщение от Нубий-IV Зачем? Все равно его надо собирать под разные версии. В моем наборе команд была папка с исходниками (одна-единственная, неизменная), и несколько файлов VS-2008.sln, VS-2012.sln, VS-2017.sln, VS-2018.sln, VS-2019.sln, в каждом из которых были свои настройки для акадов с 2005 по 2019, в каждом по несколько проектов, для всех поддерживаемых версий. Тут можно сделать так же, только еще и под нанокад настройки добавятся (теоретически они должны те же исходники переваривать, только я это еще не проверил, у меня студии не Pro).

Оставляем пока проект как есть? Нубий-IV сможет в нем участвовать?
Может версию студии понизить?

[Нубий-IV]

Сообщение от nickname2019 Может версию студии понизить?

Исходники должны оставаться одними и теми же (по крайней мере, так обещают). А студию каждый может использовать какую хочет. Точнее, какую надо под свою версию акада или нанокада (у меня, видимо, обязана быть 2008pro). Просто можно накидать несколько файлов SLN рядом, каждый под свою версию студии.

В моих командах единственная вещь, которую пришлось сделать в исходниках - поставить в общем заголовке условную компиляцию, подменяющую один-единственный тип данных, который при смене версий в ObjectARX поменялся:

Код:

[Выделить все]

 #if	defined(RK_2008x32) || \
	defined(RK_2009x32) || \
	defined(RK_2010x32) || \
	defined(RK_2008x64) || \
	defined(RK_2009x64) || \
	defined(RK_2010x64)
		#define AdInt32 long
#endif

И в файлах проектов был задан соответствующий DEFINE для каждой версии. И тут должно быть что-то такое же.

Кстати, по ссылке выше описано использование страниц свойств для быстрой подмены настроек проекта. Если у каждого будет своя локальная страница свойств, можно не привязываться и к конкретным путям и версиям ObjectARX или автокада. А возможность один локальный файл настроек не синхронизировать наверняка есть у гитхаба.