core libs inconsistencies

danomatika commented 11 years ago

In writing Apothecary, I noticed a number of small inconsistencies in the libs folders. I'm noting them here.

Assimp

Why is assimp needed for osx in the core libs? I'd think we'd want it in ofxAssimpModelLoader/libs.

Freetype weird nested folder structure

The include path is freetype/include/freetype2/freetype instead of freetype/include.

I assume this is due to weird include paths in freetype?

FreeImage naming

Shouldn't "FreeImage" be "freeimage" to match the lower case lib name convention in OF?

tess2

I'd think the tess2/Sources folder should be tess2/src

Also, the compiled library has the "lib" prefix while all other libraries are renamed without it:

libtess2.a -> tess2.a

rtAudio naming

Shouldn't "rtAudio" be "rtaudio" to match OF lower cased lib name conventions?

Cairo

The win_cb libraries all have the "lib" prefix, while the other cairo platform builds do not.

bakercp commented 11 years ago

Just to add to this discussion as someone working with the make system and OS X ... I really think we should name libraries with the standard libMyLibrary.so/a pattern rather than picking arbitrary un-prefixed names. @arturoc mentioned that this was done early on to prevent name clashes with system libs, but I think we've probably got that under control now ... right?

danomatika commented 11 years ago

I also agree with this. It's best to use the standard lib name where possible.

danomatika commented 11 years ago

In writing Apothecary, I took the approach to match the current conventions which seem to be:

lower case lib names over camelCase/CamelCase
no "lib" prefix
folder layout:

somelib/include somelib/src somelib/lib

arturoc commented 11 years ago

assimp is an error, we had assimp in the core for a while while developing 007 and then we never moved it to addons for osx
freetype comes like that in their download, if you look in inlcudes they have that folder structure, same in linux: /usr/include/freetype2/freetype/
Freeimage: yes probably but their include files are also capitalized so not sure
tess2: yes, we could even have that one build from source somehow
rtaudio: same thing as Freeimage, except in this case the includes are RtAudio! :)
cairo: not sure, in osx we remove the lib prefix to not have problems with libraries in the system but not for any other platform i think

i think in general:

osx & vs: no prefix (in vs is actually the standard but not for *nix including mingw) rest of the platforms: prefixed with lib

as for the capitalization i'm ok with moving everything to lower case or leave it as the standard for that library (ie: freetype would be correct but not rtaudio)

danomatika commented 11 years ago

I have tess2 built in Apothecary for both osx and ios. I actually made a CMakeLists.txt for it and let cmake do the rest, which us what they do in Homebrew.

ofTheo commented 11 years ago

Actually there is a very good reason we don't do libMyLib.a in OS X.

Xcode had ( and I think still does ) a quirk where it would link against a library in /usr/local/lib if that lib was present ( only if it began with the lib prefix ). So if opencv in OF was named libOpenCv.a and you happened to install OpenCV to your system path, then your app is linked to that lib not the one in OF. This creates major problems, especially when you give the app to someone else and they don't have opencv installed.

Anyway, this is the reason why we do opencv.a instead of libopencv.a in OF for OS X. It might be that this has been fixed, but my guess is it hasn't.

ofTheo commented 10 years ago

okay - I can confirm this issue still exists on xcode. I had a library ( libmicrohttpd.a ) that would not link to the app without removing the lib prefix from it.

so my suggestion is still to drop the lib prefix for all OS X libraries.

pizthewiz commented 10 years ago

Would this suggest that /usr/local/lib is polluting the LIBRARY_SEARCH_PATH? cc @admsyn

ofTheo commented 10 years ago

yes exactly.

ofTheo commented 10 years ago

@bakercp I just tried to make my own lib to demonstrate the issue. I wasn't able to reproduce it with my own library.

I could be that it is solved in the latest Xcode but at the same time I have seen this issue crop up frequently enough and be incredibly frustrating to debug ( especially with dylibs, when people send apps to clients and the lib is trying to dynamically link to /usr/local/lib ), that I would rather error on the side of caution.

bilderbuchi commented 10 years ago

It's strange, shouldn't this kind of issue normally be solved with precedence on $PATH? I.e. whatever comes first on the search path gets linked, and if you got some path of higher precedence, you just _pre_pend it on the relevant environment variable? could it be the same in the XCode project files (i.e. we just got the order of paths in some config line wrong, and usr/local/lib comes first), if it doesn't use env. vars? I know python does module search that way, with $PYTHONPATH.

aubergene commented 5 years ago

I've just started using openFrameworks today. I was trying to compile the 3DPrimitivesExample and got an error that it couldn't find openFrameworks/libs/rtAudio/lib/osx/rtAudio.a this was because I'm using case sensitive APFS, so I renamed the file. It would be great if it could be fixed upstream for new users. I had a look in the source but couldn't figure out where it needs to be fixed.

openframeworks / openFrameworks