visual studio: environment vars in paths?

[jeffcrouse]

I am trying to write an install.xml for a MS Kinect addon. It needs:

1. A bunch of src and additional include directories -- this all works great!
2. "$(KINECTSDK10_DIR)/inc" as an include directory
3. "$(KINECTSDK10_DIR)/lib/(x86|amd64)/" as a library search path
4. "Kinect10.lib" and a few libs from "$(VCInstallDir)/lib" as additional dependencies

Here is what I have so far: https://github.com/jefftimesten/ofxKinectNui/blob/master/install.xml

Are environment variables allowed? Are they filtered out as not valid paths somewhere? Or perhaps filtered out because they aren't in the addon directory? If so, is it too risky to allow linking to libraries outside of the oF directory?

I am about to start reading through visualStudioProject.cpp, but if anyone has any hints, I'd be much obliged.

[ofTheo]

not sure about the environment variables. I don't think it has ever been tried from the install.xml

do you see the value come through in the generated project?

also where is the SDK located typically on the HD? is there an option to install it at the root - or within the OF projector hierarchy?

[ofZach]

hi jeff,

first, the project generator doesn't use the install.xml at all actually, it just parses the addons folder by file structure, so you might be working in vain here. it's not that it can't (that code is written and tested) it's just that the linux way of doing things has been file structure related and so many addons don't have install.xml done or done properly.

The basic logic of the PG is:

recursively scan the src folder, and add paths to include and src to the project recursively scan the libs folder and (a) look for a libsorder.make anywhere which might specify linking order (b) look for anything that looks like a lib ("a", "lib" "dll") and add it as a linking option (add all relevant link options), take anything that looks like source ("h", "c", "cpp") and add it as src to the project and add include paths.

this is probably not enough, and it leads to some ugly hacks like this:

https://github.com/ofZach/projectGeneratorSimple/blob/master/src/utils/Utils.cpp#L333-345

so we obviously need to re think this...

we can either go a few different routes -- one is the libsorder.make route, which would mean adding more text files that get parsed, sometimes in the context:

https://github.com/openframeworks/openFrameworks/tree/master/addons/ofxOpenCv/libs/opencv/lib/android/armeabi

or sometimes more globally. Another solution might be to have an optional install.xml, which helps override or augment some settings from the file structure parsing.

the key parts of the addon parsing are here:

https://github.com/ofZach/projectGeneratorSimple/blob/master/src/addons/ofAddon.cpp

• there's alot of functions in utils that do recursive stuff, etc.

I know this isn't an answer, but I hope it helps. Curious what you think a good solution is....

[ofZach]

ps: this is a fairly good template for the way we are parsing addons right now:

https://github.com/benben/ofxAddonTemplate

it obviously doesn't help for adding paths / libs outside of the addons folder itself, and the current setup probably won't work for you yet / needs to be expanded.