I have been trying to get the shaders test to build but I have run into lots of issues with linking dependencies, exports imports etc.

The projects cmake generates for example oslquery uses source files from olsexec. This is causing issues with the DLL_PUBLIC etc type of declerations, because other projects use oslexec as a library to import.
I guess this may work fine on GCC but windows is pitches a fit, because in one project the defines are correct import/export in the other they are import when they should be nothing or export.

Are the source files being duplicated in the projects on purpose? Is this just a cmake issue? 
Is this just an issue with VS because GCC doesn;t care and just links everything together?

I think i should be able to rearrange the import/export types for windows, and then make olsquery have a depencency to oslexec instead of rebuilding the lexer etc. And for any of the other projects(i think the others are better).
And make sure the projects use the library imports rather than building the code themselves?

Or should i get them to build duplicating the code in areas and just fix the special cases with more defines.

I prefer the first option, and at first i could probably isolate it to windows in cmake and the source. But maybe its a issue for gcc as well in some areas.
Or maybe oslquery needs to run standalone you dont want to inlcude a dll/so.

Any thoughts?

Jeremy

On Thu, Jan 21, 2010 at 12:39 AM, Wormszer <worm...@...> wrote:

I have mcpp integrated into the compiler now. Working like CPP and writing everything to stdout.

A few things, the binary available for download at least on windows doesn't support forcing an include file.
So i had to build it from source, luckily it wasn't to difficult to create a new project for it.

I built it as VS for VS. Now that I think about it I bet I could build it as VS for GCC so that it would support the same command line options.

Another weird issue was I guess the lexer doesn't support  c-style /* comments? These might not be defined in the osl language, and if so probably should be removed from the stdosl.h.
Its the only difference i could see, that could of been causing the error.

CL would remove the */ */ comments at the end of the math defines in stdosl.h even though i told it to preserve comments.

mcpp when i told it to leave comments would actually leave them in there(seems like correct behavior), and then the lexer would crash.

I am not sure why comments are needed really at this point, and i think i must of included them for my own debugging, i don't think CPP was set to output them.

Thanks for the suggestions on a easier solution to the pre-processor issue.

I looked real quick for the boost but mcpp seemed easier since i could just get a binary and set it in my path. (but then i had to rebuild it)

Well now to see if I can get anything to happen with my compiled shaders.

Jeremy

On Wed, Jan 20, 2010 at 9:03 PM, Wormszer <worm...@...> wrote:

I am fine with either one. I think having something embedded or buildable would be usefull.

Otherwise there maybe issues with different compilers and would probably need some kind of config or something that cmake would generate at least on windows with several versions of VS etc.

Will just have to see how Larry or the other devs feel about using one of those two for Linux builds as well. I would assume it would be wise to have all the preprocessing done with the same tool when possible.

I will look at both real quick but I might lean towards mcpp.

On Jan 20, 2010, at 8:14 PM, Chris Foster <chri...@...> wrote:

On Thu, Jan 21, 2010 at 11:02 AM, Blair Zajac <bl...@...> wrote:

The main annoyance with wave is that it causes the compiler to issue truly
horrendous error messages if you get things wrong (the wave internals make
heavy use of template metaprogramming).

(Obviously this is only a problem when integrating wave into the project
source, and that's not really difficult at all.)

There's mcpp which is designed to be an embeddable C-preprocessor.

Ice, which we use at Sony Imageworks for all our middle-tier systems, uses
mcpp for it's own internal IDL type language, so I would recommend that.

mcpp looks nice.  In some sense, using wave would mean one less dependency
since OSL already relies on boost, but it does mean linking to libboost-wave,
so if you have a modular boost install the point may be moot...

~Chris

PS: Sorry to Blair for the duplicate message.  I intended to send it
to the list :-(

--

You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To post to this group, send email to osl...@....
To unsubscribe from this group, send email to osl...@....
For more options, visit this group at http://groups.google.com/group/osl-dev?hl=en.