Hello,

I'm accustomed to using the #include pre-processor in my vex wrangles for my own functions stored in external files.

I don't have issues with using #include for those functions; It works fine.

However, when I simply want to insert a ‘block’ of code using #include that is accessing that block of code from a file, it complains with error messages.

Depending on the block of code the error( fail to cook, vex and during comile errors) always refers to some punctuator of the code in the external file with something like:


The code which is in the external file(Code_Insert.h) is :


The line in vex used to access that file is the typical way I use #include for my functions as:


I've tried just using quotes instead of <>, but no difference.

The above code is just a simplified example which duplicates what I was experiencing in my original file.

From the docs:

…

#include “filename”

Inserts the contents of the file at this point in the source code. When you use quotes, the directory containing the current file is searched for filename before the standard locations (including the path).

…

Base on this doc description I was assuming my block of code would be inserted in the wrangle where I have the #include statement, but the error messages say otherwise.

Anyone know what I may be mis-understanding or doing wrong?

Thanks

That documentation would be for normal VEX code.

In Wrangles the VEX code is transformed in several ways before going to the compiler. This includes pulling out all the @ variables and renaming them, for example.

One important thing to note about wrangles is that everything you write is *inside* a function. So when you write


The snippet will generate


and invoke the somelongname function from the relevant place of the CVEX shader. Thus, while your code looks like it is in the outermost scope of a .vfl file, it isn't. It is actually inside of a function. So if we tried to take a standard header like math.h and drop it in there, weird and horrible stuff would happen.

Thus, one pre-processing step is to take all the #include lines in your wrangle and move them outside of that somelongname function. This works well when you define functions. It doesn't work well when you try to insert code blocks.

Being able to nicely insert code blocks into wrangles is sadly something we don't have a good solution for. Some people go with


but this has its own list of problems.

Thank you very much for that explaination jlait; I was waiting for some explanation from someone instead of assuming some kind of ‘bug’ and reporting it.

Your explanation also confirmed something else I was curious about and noticed the other day when working in Detail mode - which I thought it seemed like exactly what you said - it was like the code was ‘pre-parsed’ looking at all the @ variables first, before executing the code.

It seems that requesting an rfe for that(external bloc of code file) would likely take alot of work to implement, judging by your explanation of what is typically happening. So I will refrain from making the request

It's not a big issue, but I am finding it adds to the “power” of using vex by being able to ‘simplify’ what code one sees in their own wrangles.

That's why I started down the road of writing my own functions off into a header files.

Where once I might have 1500 lines of code in a wrangle, after sorting that code into functions; I get those wrangles down to like 5-20 lines of code.

Because of this, one is able to begin mixing different different functions for different purposes in their wrangles in a very quick way, since one is going by their function names, instead of sifting through many lines of code.

I think I'm using wrangles in a way not originally intended, but at the same time; With further development, or even an overhaul from the ground up, using wrangles in a more expanded scope I think has great potential.

On the other hand, I think one might suggest at this point, to go more down the road I already am, it may be time to dig into the HDK and work from there.

Isn't this what macros are for?

What do you mean? Macros in vex?

Yes, VEX macros–compiler pre-processor directives. If you look at the built-in source, macros are used all over for exactly the purpose you propose, to insert code, and simplify source to be more readable.

http://www.sidefx.com/docs/houdini/vex/vcc#pre-processor [www.sidefx.com]
https://gcc.gnu.org/onlinedocs/cpp/Macros.html [gcc.gnu.org]

Sidefx' own built in vex code is a great source for learning this stuff. Go to the vex folder in the houdini install directory and read all the source. It's also a good way to see what problems may already be solved in a header file in the include path.

C-language resources are mostly applicable to VEX, as the language shares much of the structure of C.

hmm yes..been too long since I've written a c program.

Forgot about macros, although I only ever used them for very simple things like one line definitions for screen background color, screen size, etc.

But the info at those links should be enough to get me up to speed and learn how to do what I intend.

If I have trouble, I'll just post a new topic here or even go to a c forum.

Thanks for the tip.