Let .use files be version-aware, dammit! #561

Closed
nddrylliog opened this Issue Feb 8, 2013 · 4 comments

Projects

None yet

2 participants

@nddrylliog
Member

So.. I've added stuff like AndroidLibs and AndroidIncludePaths in 95x but really, really I'm not happy with it.

How about this instead?

deadlogger.use

Name: deadlogger
Description: A dead (-simple) logging package for ooc
SourcePath: source

version(android) {
  Libs: -llog
}

sdl2-opengl.use

Name: SDL 2.0 OpenGL support
Description: OpenGL headers + libraries for SDL2 
Requires: sdl2 

version (android || ios) {
  Libs: -lGLESv2
  Includes: SDL_opengles2.h
} else {
  # Use regular OpenGL 2.x on Desktop
  Includes: SDL_opengl.h

  version (windows) {
    Libs: -lopengl32
  }
  version (linux) {
    Libs: -lGL
  }
  version (apple) {
    Frameworks: Carbon, OpenGL
  }
}

The sdl2-opengl example is as hairy as it gets (imho), and we haven't even touched iOS yet.. but you get the idea.

I think with that we might be able to generate more robust Makefiles, flawless Android.mk, and even CMakeLists, who knows. And of course SequenceDriver will work splendidly on all platforms as well.

The current workaround is to have separate different .use files and hack OOC_LIBS to make rock find the right ones.. but that shouldn't be needed - the sdl2-opengl file above will actually be equivalent to these files, depending on your platform:

Android/iOS

Name: SDL 2.0 OpenGL support
Description: OpenGL headers + libraries for SDL2 
Requires: sdl2 

Libs: -lGLESv2
Includes: SDL_opengles2.h

Windows

Name: SDL 2.0 OpenGL support
Description: OpenGL headers + libraries for SDL2 
Requires: sdl2 

Includes: SDL_opengl.h
Libs: -lopengl32

Linux

Name: SDL 2.0 OpenGL support
Description: OpenGL headers + libraries for SDL2 
Requires: sdl2 

Includes: SDL_opengl.h
Libs: -lGL

OS/X

Name: SDL 2.0 OpenGL support
Description: OpenGL headers + libraries for SDL2 
Requires: sdl2 

Includes: SDL_opengl.h
Frameworks: Carbon, OpenGL

That will mean a lot more logic in the generate Makefiles though..

Android.mk is easy because there's only a single target. And the above conditions should translate pretty effortlessly in cmake's bastard scripting language. But for Makefile.. the really fun will begin :)

@duckinator
Collaborator

I may or may not have* just made a strange noise because of how FUCKING AWESOME this idea is.

* And by "may or may not have" I mean "definitely"

@nddrylliog
Member

A few things to note:

  • This makes our hopes go away to make our file format resemble YAML (or even pkg-config .pc files)
  • We'll need a stack to parse that, just like version blocks in .ooc files
  • It might be useful to have a greg grammar for that, although I only know three pieces of software who parse usefiles for now: rock, sam, and (the defunct?) reincarnate. It should be easy to ignore for the pieces of software who don't care tho.
@nddrylliog
Member

More notes:

  • There are still things we can't get away with without android-specific .use files properties - Android.mk have a system of dependencies to know what to build. If you stay in pure-ooc-land that's cool, but let's take this Android.mk for example:
LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE := sdl2
LOCAL_C_INCLUDES := $(LOCAL_PATH)/../sdk $(LOCAL_PATH)/../sdl2 $(LOCAL_PATH)/../gc/include $(LOCAL_PATH)/../SDL/include 

LOCAL_SRC_FILES := source/sdl2/Core.c source/sdl2/OpenGL.c source/sdl2/Event.c 
LOCAL_SHARED_LIBRARIES := gc gc SDL2 sdk 

LOCAL_LDLIBS := -lGLESv2 

include $(BUILD_SHARED_LIBRARY)

It's the one for ooc-sdl2. The .use file has those android-specific flags:

AndroidLibs: SDL2
AndroidIncludePaths: ../SDL/include

This is actually very touchy because it depends on how you use SDL - have you cross-compiled it yourself, or do you use it as they say - ie. using their android project skeleton and having 'SDL' symlinked in your jni/ ? I do as they say so ../SDL/include works for me, but it might not be for everyone.

Similarly, for libyaml, you could have:

AndroidLibs: libyaml
AndroidIncludePaths: ../libyaml/include

That assumes you've cross-compiled libyaml yourself (for example with this Android cross-compile autotools script and following this piece of advice about autoreconf) and then installed it using jni/libyaml as your prefix.

So your android project tree looks something like this:

yourproject
  - yourproject.use
  - source
    - stuff here
  - android
    - AndroidManifest.xml
    - build.xml
    - lots of other android crap
    - jni
      - Android.mk
      - yourproject
        - stuff generated by rock from your sources
      - yaml
        - stuff generated by rock from ooc-yaml
      - libyaml
        - include
          - yaml.h or something
        - lib
          - libyaml.so or something

And if you're wondering, the way you'd generate that android stuff with rock is to launch this in your project directory:

rock --driver=android --outpath=android/jni

So in that case, jni/yaml is in fact ooc-yaml, and jni/libyaml is the C library, cross-compiled.

Which works wonders. But it means we have to have some sort of consensus on how to name cross-compiled libraries.. Also at some point I wonder if having a repository of formulas (a-la homebrew/sam) on how to cross-compile libraries to Android to make it easier to use them. Or even provide compiled versions, you know, it's just a bunch of .h/.so/.a files after all.

I'm only rambling here, but it feels good to write about what I do :)

@nddrylliog
Member

Fixed in 96x

@nddrylliog nddrylliog closed this Feb 20, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment