Revision: 77778
http://sourceforge.net/p/brlcad/code/77778
Author: starseeker
Date: 2020-11-21 02:32:30 +0000 (Sat, 21 Nov 2020)
Log Message:
-----------
OpenBSD breaks naming assumptions. Need to consider how best to deal with this
- building everything with CMake has sheltered us from the chaos of cross
platform naming conventions, but now we're dealing with the native build system
outputs so we're going to have to address it somehow...
Modified Paths:
--------------
brlcad/branches/extbuild/src/other/ext/CMakeLists.txt
Modified: brlcad/branches/extbuild/src/other/ext/CMakeLists.txt
===================================================================
--- brlcad/branches/extbuild/src/other/ext/CMakeLists.txt 2020-11-21
00:13:12 UTC (rev 77777)
+++ brlcad/branches/extbuild/src/other/ext/CMakeLists.txt 2020-11-21
02:32:30 UTC (rev 77778)
@@ -26,12 +26,11 @@
#
#-----------------------------------------------------------------------
-# TODO - I oversimplified. Despite both being .lib files generated by
-# MSVC compilations, static and import libraries are *not* the same
-# thing:
https://stackoverflow.com/questions/6402586/know-if-lib-is-static-or-import
-# Need to go through and make sure static .lib build outputs aren't stomping
-# on .lib files from shared builds, and then will need to adjust the
-# ExternalProject importing logic to handle different MSVC names. Ugh.
+# Yuck - OpenBSD has it's own naming convention for executables and
+# libraries, which is messing up both our copying logic and the
+# find_package results. Will have to try to handle it - beginning
+# to wonder if we need a function to encapsulate the platform
+# naming conventions to avoid all these boilerplate patterns...
project(BDEPS)
This was sent by the SourceForge.net collaborative development platform, the
world's largest Open Source development site.
_______________________________________________
BRL-CAD Source Commits mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-commits
