Я поддерживаю многоплатформенный проект, который также компилируется для Cygwin. Я хочу предоставить библиотеки и двоичные файлы для 4-х различных "Cygwin-МОГ" нацеленСоглашение Cygwin для именования/размещения нескольких целевых библиотек
- 32-битный CYGWIN
- 32-битный MingW
- 64-битный CYGWIN
- 64-битный MingW
Каким будет соглашение Cygwin для предоставления всех четырех из них?
Существует две части этого: двоичный, назовем его «бегуном» и библиотекой («library»), которая является динамически загружаемой общей библиотекой, DLL.
Пользователь будет строить .dll для одной из целей, используя кросс-компилятор или собственный. (S) Он будет использовать бегун, который, среди прочего, загрузит предоставленную пользователем DLL и библиотеку. Очевидно, цель для всех трех должна соответствовать.
Бинарники обычно запускаются от /usr/bin или /usr/local/bin, и на DLL-платформах динамические библиотеки будут загружаться из того же места или из каталога в пути. Поскольку пользователь также будет связывать DLL с библиотекой, требуется liblibrary.dll.a, обычно хранящийся в /usr/lib или /usr/local/lib.
Существуют две основные стратегии, которые я могу видеть
- предоставляют библиотеки и двоичные файлы с разными именами, но в тех же местах и,
- , обеспечивающие библиотеки и исполняемые файлы с одинаковыми именами, но в разных местах.
Стратегия 1 привела бы к /usr/bin/runner-32-cygwin и т. Д., А библиотеки и библиотеки DLL: с похожими именами. Сложности включают в себя то, что пользователю нужно будет понять именование, запустить «неестественные» именованные двоичные файлы и разные .dll.a: s нужно ссылаться/указывать на разные DLL: s.
Стратегия 2 приведет к сложностям в связывании и путях выполнения, включая пути, такие как /usr/bin-32-cygwin или некоторые из них.
Есть ли конвенция или общепринятая мудрость, чтобы справиться с этим? Я также хотел бы оценить любые дополнительные идеи и/или мысли по этому вопросу или поправки к моим предположениям.