Menu
▾
▴
1 Attachments
#569 It is not possible to use relative paths for "generated files" in advanced compiler options
As described here:
http://forums.codeblocks.org/index.php/topic,22222.msg151278/topicseen.html#msg151278
it is not possible to use relative paths for the generated files in advanced compiler options.
To reproduce this you need a custom compiler that generates a file. I use protobuffer for this example. Go to Settings->compiler->Other settings->advanced options
1) Create a new extension handler with "proto"
2) Add this in "Command line macro"
protoc -I$file_dir --cpp_out=proto $file
3) Add this in "Generated files"
proto/$file_name.pb.cc proto/$file_name.pb.h
attached is a example project to build
The intended behavior is to create the output files in a subdirectory "proto" in the current project directory. The protoc compiler generated the files but codeblocks can not find them because it expected them in the same directory as the .proto file. The "Generated files" tells codeblocks to search in the "proto" sub directory of the current project
As described in the forum thread the problem is in sdk/subproject.cpp:830
tmp.SetFullName(tool->generatedFiles[i]);
SetFullName will swallow all paths and make it unable to use relative paths (at least wx3.0 on linux).
If we look at the other generate commands, for example for y extension, the generated files are:
$file_dir/$file_name.parser.cc $file_dir/$file_name.parser.hh
so there is no need to search for a relative file path to the generated file in the code. It is possible to use the "$file_dir" macro to put the file into the directory of the description file.
I even think that this is a unnoticed bug in the current implementation because the "$file_dir" part is simply ignored, but the file is nevertheless searched in the right location by accident.
This is another change which I think it is too dangerous to be done at this moment. So I'll postpone it a bit after the release, so we can do more extensive testing without hurting anyone.