#include

[Synide 0]

Is it possible to use a relative pathname in your #include preprocessor directives that goes up and out of your current folder as oppossed to drilling down through subfolders only?

That is you've always been able to do...

         #include "filename.ext"

         #include "subfolder\filename.ext"

but can you do...

         #include "..\common\filename.ext"

I can't seem to get it to work... what I don't want to do is have 'commondefines.hpp' present in every folder and have to maintain there integrity. I just want one (1) version of the file that I need to maintain.

[Synide 0]

ahh... how stupid of me...

you can use...

#include "../adifferentfolder/filename.ext"

if you 'preprocess' all the config.cpp into config.bin with cfgconvert.exe AND remove or rename the text version so binarize.exe doesn't find it... cool - sorry answered my own question.

disregard. cheers.

[General Barron 0]

Another alternative. Let's say your addon is located at P:\ca\myAddon, and your common defines are located at P:\ca\commonDefs.hpp. At the top of your config, you would write:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">#include "\ca\commonDefs.hpp"

Note it is basically the path to the file, without the P: suffix (you already have told configConvert that P: is your root folder somewhere else during the setup process).

Also, remember that the include happens when you PACK the addon, not when you start the game. So in this example, "commonDefs.hpp" doesn't have to exist inside of "ca.pbo" for your config to load correctly when you run Arma.

On the flip side, if commonDefs.hpp does exist in ca.pbo, changing it AFTER you have packed your addon will not change your addon's config.

[.kju 3245]

Quote[/b] ]Also, remember that the include happens when you PACK the addon, not when you start the game. So in this example, "commonDefs.hpp" doesn't have to exist inside of "ca.pbo" for your config to load correctly when you run Arma.

On the flip side, if commonDefs.hpp does exist in ca.pbo, changing it AFTER you have packed your addon will not change your addon's config.

This is not necessarily true from what I know.

It depends on the settings of packaging / the packing tool.

The content of the to be included file can be integrated but most not.

You can even put includes to files outside of pbos and change

their content each time before you load ArmA.

So in other words ArmA does load the include each time again

in this case.

[General Barron 0]

This is not necessarily true from what I know.

It depends on the settings of packaging / the packing tool.

The content of the to be included file can be integrated but most not.

Yes, you are right, I should have been more specific.

If you are using BIS's pbo packer, it runs a program called cfgConvert. This program will "rapify" and preprocess your config, which means it will resolve all #includes, #defines, EXECs, etc when you pack.

If you don't use BIS's pbo packer (or a 3rd party program that does config conversion), then Arma will do this process when you load the game. In this case, the #includes are resolved at load-time, and obviously changes in the those files will change the way the config is loaded.

Both methods have their uses. Obviously, the load time for Arma will be a tiny bit slower if it has to preprocess a config or binarize a model. If the whole BIS content was like this, then it would most likely be very noticeably slower to load; but for a user addon here and there, I don't think it matters enough to worry about.

------

edit

------

For the benefit of searchers/others, here is how you #include a file that is outside of a pbo:

#include "\whatever\something.hpp"

Now, the thing to remember is that the game will start looking for the file relative to your Arma installation directory.

So, lets say Arma is installed at C:\arma.

In the above example, the game would look for the following file:

C:\arma\whatever\something.hpp

The same goes for any other file; for example, you can run a script out of your Arma directory using:

[] exec "\whatever\myscript.sqs"

(Or you could point to a picture for a dialog, etc etc.)

When referring to stuff inside of a pbo, the pathing process is a bit different. In this case, use the instructions in my first post: basically, you use its path in the P: drive, minus the "P:" prefix.

[Synide 0]

while that's all interesting i'm not talking about Runtime side of things just the Build side of things... and i already know the stuff your both talking about...

what i'm talking about is this... I want a single commondefines.hpp sitting somewhere in P:\Synide build structure so that when all config's are processed during build at the start of each config it includes the one and only commondefines.hpp so I don't have to have dozen's of versions of the same file stuck in every subfolder... Like the BIS guys do... have a look for 'basicdefines.hpp' in BIS's example mlod/config's released.

I appreciate the additional info... which unfortunately I'm already well aware of that stuff... I have worked out what I needed to know myself... and achieved what I wanted, a single commondefines.hpp so I only have to manage the one file.

@General Barron...

while you are quite correct about how CfgConvert.exe operates and it's very nice that it parses 'relative' pathspecs... the resultant output of CfgConvert's efforts is not utilized by Binarize.exe.

Binarize.exe re-parses the text version of the config's again on it's own... and Binarize.exe does not like relative paths... it only allows you to specify an include file in the same folder or a subfolder.

Example...

In a config located at P:\Synide\synBodies\config.cpp

You can't use...

       #include "P:\Synide\commondefines.hpp"

       #include "\Synide\commondefines.hpp"

       #include "..\commondefines.hpp"

to get to the file 'commondefines.hpp' located in 'P:\Synide'. - Binarize.exe will kick up a stink.

To get Binarize.exe to parse this 'P:\Synide\synBodies\config.cpp' properly i'd have to move a copy of 'commondefines.hpp' into the same folder or a subfolder and do the include statement as follows...

       #include "commondefines.hpp"

        OR

        #include "hpp\commondefines.hpp" - if I moved a copy into P:\Synide\synBodies\hpp folder for instance.

The way around all this is to 'pre-convert' the text file using CfgConvert.exe (which does support relative pathspecs) before even starting up BinPBO leaving just an already processed config.bin sitting in P:\Synide\synBodies.

Then when Binarize.exe gets run (via BinPBO) all it finds is a pre-converted config.bin file and happily continues on it's build...

[General Barron 0]

Quote[/b] ]...and i already know the stuff your both talking about...

How am I supposed to know what you do and do not know? Also, I like to include extra information for the sake of others that might be browsing the topic.

Quote[/b] ]to get to the file 'commondefines.hpp' located in 'P:\Synide'. - Binarize.exe will kick up a stink.

Ok, that sucks. Sounds like a problem with BinPBO not passing the right info to binarize, just to configConvert? I dunno. Maybe try using the -prefix switch when running BinPBO, with a prefix of "P:".

Quote[/b] ]-PREFIX: relative path to files used in addon, if not present then this value is calculated automatically.

http://community.bistudio.com/wiki/BinPBO_Manual

[Synide 0]

How am I supposed to know what you do and do not know?

while that is true I did write in the second post in this thread that I'd worked out what I needed and didn't require further assistance... there's is not much I don't know (or can't work out) about ArmA tbh, I even know stuff that some BIS dev's don't know... Kinda a shame really...

Quote[/b] ]Ok, that sucks. Sounds like a problem with BinPBO not passing the right info to binarize, just to configConvert? I dunno.

Nah... I'm pretty sure that Binarize.exe has never been able to parse 'relative' includes... sure, it can parse an include that points to a file in the same folder or a subfolder... but not "..\..\..\somefolder\common.hpp" syntax.

As CfgConvert.exe has been written relatively recently obviously it's coded a little more thoughtfully. But, currently the two don't interact in any way... I'd prefer if the cumulative rapified output from CfgConvert.exe was passed to binarize.exe instead of binarize re-parsing the stuff again... or some alternate method that provides the same results.

Regarding suggested -prefix commandline parameter for BinPBO... Nah... that tells BinPBO to tell Filebank to embeded the given 'Addon' prefix into the header of the .pbo...

[.kju 3245]

There is always the option NOT to binarize?!

[General Barron 0]

while that is true I did write in the second post in this thread that I'd worked out what I needed and didn't require further assistance... there's is not much I don't know (or can't work out) about ArmA tbh, I even know stuff that some BIS dev's don't know... Kinda a shame really...

While I'm sure that we are all impressed, do remember that this is a public forum, not a PM. So posts that I make are not only intended for you, but for the benefit of everyone else. If you already know the things I am describing, then good for you; but boasting to the world isn't gonna stop me from trying to write posts that others might find useful.

-------

Anyway, I think I'm venturing into the realm of flaming, so the mods can feel free to slap me if I'm out of place. I have nothing more to add to the current thread, I've already given my thoughts, and apparently they don't work.

[Synide 0]

while that is true I did write in the second post in this thread that I'd worked out what I needed and didn't require further assistance... there's is not much I don't know (or can't work out) about ArmA tbh, I even know stuff that some BIS dev's don't know... Kinda a shame really...

While I'm sure that we are all impressed, do remember that this is a public forum, not a PM. So posts that I make are not only intended for you, but for the benefit of everyone else. If you already know the things I am describing, then good for you; but boasting to the world isn't gonna stop me from trying to write posts that others might find useful.

-------

Anyway, I think I'm venturing into the realm of flaming, so the mods can feel free to slap me if I'm out of place. I have nothing more to add to the current thread, I've already given my thoughts, and apparently they don't work.

Oh, dear me... Anyway, to summarize...

If on the Build side of things you want to use 'relative' #include preprocessor statements in your config's you can if you do the following.

1. Prior to running BinPBO convert your config.cpp to it's rapified config.bin equivalent using CfgConvert.exe. (Which can handle 'relative' #includes.

2. Remove or rename the config.cpp so that Binarize.exe can't find it and has to use the config.bin instead.

@GB... I'm sorry I offended your sensibilities. I apologise.

I'm sure some people will find your posts most illuminating.

[UNN 0]

Quote[/b] ]There is always the option NOT to binarize?!

I don't have any choice. BinPBO crashes, as soon as I run it with binarize checked

[.kju 3245]

ehm sorry?!

Run it with binarize option unchecked?!