Code::Blocks Forums
User forums => Help => Topic started by: christobal on November 30, 2009, 11:11:33 am
-
Hi,
Does anybody know, if there is a Code::Blocks variable (like e.g. $(PROJECT_NAME)) for the Compiler Installation Directory? I could of course create a custom variable for that, but the downside would be that my projects won't be compileable on other machines.
-
Hi,
Does anybody know, if there is a Code::Blocks variable (like e.g. $(PROJECT_NAME)) for the Compiler Installation Directory? I could of course create a custom variable for that, but the downside would be that my projects won't be compileable on other machines.
I just do a quick search about "PROJECT_NAME" in the codeblocks source code
"sdk\macrosmanager.cpp" will do the whole job, but I can't find a Code::Blocks variable of compiler installation path, so, I think you can add one in that file. :D
-
christobal: Why do you need it?
-
christobal: Why do you need it?
I need to run some scripts in the post-build steps, which need the compiler path (basically extracting object files from one lib and putting them into another).
"sdk\macrosmanager.cpp" will do the whole job, but I can't find a Code::Blocks variable of compiler installation path, so, I think you can add one in that file.
Adding that variable to the macrosmanager is an easy task, but since I will share my projects with others, it will fail for everyone who has the "official" Code::Blocks installed.
Maybe I should file a feature request...
-
I've expected the answer to be weird, but that weird :lol: :shock:
Adding that variable to the macrosmanager is an easy task, but since I will share my projects with others, it will fail for everyone who has the "official" Code::Blocks installed.
Maybe I should file a feature request...
Better route for you is to upload a patch to berlios.de
-
I've expected the answer to be weird, but that weird :lol: :shock:
My build target is a static library. Some of the object files are generated from the sources and some are copied from another library. I wouldn't say that it's weird... But if you know a better way to move object files from one lib to another, please tell me :wink:.
-
I suggest using an environmental/system variable if it is just Windows; not sure if this would work with Linux.
Tim S.
-
Global variables is what you are looking for. Once defined if you open the project file on another computer C::B will query (once) for the location of the compiler. This way you can assure that the setup is correct on the target platform. This works cross-platform, of course.
Same applies to e.g. libraries like boost. Just define a global variable and it'll be qeried on another compuert (even another account) if not defined there.
-
My build target is a static library. Some of the object files are generated from the sources and some are copied from another library. I wouldn't say that it's weird... But if you know a better way to move object files from one lib to another, please tell me :wink:.
If the object files from the other library are propriatary you won't have any other chance most likely. However, if you have access to the sources I'd rather compile them (another time) to avoid e.g. ABI incompatibilities. It always shiffers me if I have to use object files I can't compile myself. I even had to abandon a whole project back in the days because the provided object files were not compatible with new kernel versions and were not updated anymore. When we bought the 3rd party stuff (for tons of money, of course) it was said "life-time support".... Tssss. Life-time assholes probably, but that's it. You see: This can be mission-critical.
-
Global variables is what you are looking for. Once defined if you open the project file on another computer C::B will query (once) for the location of the compiler. This way you can assure that the setup is correct on the target platform. This works cross-platform, of course.
Same applies to e.g. libraries like boost. Just define a global variable and it'll be qeried on another compuert (even another account) if not defined there.
The Global Variables are a good solution. I will use them, thanks!