User forums > Using Code::Blocks
Passing exe filename to an external tool
thomas:
That's a valid point (although you would surely pass -s to the linker rather than call strip ;) ). But yes, you are 100% right, it is stupid to limit oneself to executables.
The wxEmptyString objection is correct, too. Should be that way.
Did you actually compile it? If so, mind making a better patch?
Urxae:
--- Quote from: thomas on August 01, 2005, 09:20:22 pm ---That's a valid point (although you would surely pass -s to the linker rather than call strip ;) ).
--- End quote ---
Actually, knowing myself I'd probably open an explorer window and right click -> strip (added manually) :D.
But that's beside the point, there are probably other reasons to pass library filenames to tools. I just couldn't think of any others at the time. Still can't. Why are you all looking at me like that? :P
--- Quote ---Did you actually compile it? If so, mind making a better patch?
--- End quote ---
Sorry, I patched it in my head. I was switching to cvs HEAD and I was bored while compiling :D.
However, continuing my trend of doing things manually, maybe this'll work:
<WARNING>Manually edited patch file, and even the original wasn't tested. This patch never touched a compiler.</WARNING>
--- Code: ---Index: src/sdk/macrosmanager.cpp
===================================================================
RCS file: /cvsroot/codeblocks/codeblocks/src/sdk/macrosmanager.cpp,v
retrieving revision 1.5
diff -u -r1.5 macrosmanager.cpp
--- src/sdk/macrosmanager.cpp 8 Jul 2005 09:49:04 -0000 1.5
+++ src/sdk/macrosmanager.cpp 1 Aug 2005 17:39:22 -0000
@@ -34,6 +34,7 @@
#include "cbproject.h"
#include "cbeditor.h"
#include "managerproxy.h"
+#include "compiletargetbase.h"
MacrosManager* MacrosManager::Get()
{
@@ -100,6 +101,7 @@
${ACTIVE_EDITOR_FILENAME}
${ALL_PROJECT_FILES}
${MAKEFILE}
+ ${OUTPUT_FILE}
${AMP} TODO: implement AddMacro() for custom macros (like this)
*/
@@ -118,7 +120,7 @@
buffer.Replace("${PROJECT_NAME}", project->GetTitle());
buffer.Replace("${PROJECT_DIR}", UnixFilename(project->GetBasePath()));
buffer.Replace("${MAKEFILE}", UnixFilename(project->GetMakefile()));
-
+ buffer.Replace("${OUTPUT_FILE}", UnixFilename(project->GetOutputFilename()));
wxString files;
for (int i = 0; i < project->GetFilesCount(); ++i)
files << UnixFilename(project->GetFile(i)->relativeFilename) << " ";
@@ -131,6 +133,7 @@
buffer.Replace("${PROJECT_DIR}", wxEmptyString);
buffer.Replace("${MAKEFILE}", wxEmptyString);
buffer.Replace("${ALL_PROJECT_FILES}", wxEmptyString);
+ buffer.Replace("${OUTPUT_FILE}", wxEmptyString);
}
EditorBase* editor = Manager::Get()->GetEditorManager()->GetActiveEditor();
--- End code ---
thomas:
Getting back to an old subject...
I felt like actually compiling this today. The attached patch introduces two new macro names, OUTPUT_FILE, and OUTPUT_DIR.
It does compile fine, but it seems to me that no macro substitution is actually done? Not only regarding the new ones, but in general? That is also true for the non-modified RC1-1 executable.
Entering
--- Code: ---echo projectdir ${PROJECT_DIR} ${PROJECT_FILENAME}
echo outputfile ${OUTPUT_FILE}
echo outputdir ${OUTPUT_DIR}
--- End code ---
into Pre-build steps gives this output for me:
--- Code: ---Project : Code::Blocks (wx2.6)
Compiler : GNU GCC Compiler (called directly)
Directory : D:\checkout\head\codeblocks\src\
--------------------------------------------------------------------------------
echo projectdir ${PROJECT_DIR} ${PROJECT_FILENAME}
projectdir
echo outputfile ${OUTPUT_FILE}
outputfile
echo outputdir ${OUTPUT_DIR}
outputdir
--- End code ---
Also, I noticed that while these macros have the syntax ${NAME}, the ones used during compilation have the syntax $(NAME). Is that intentional?
EDIT: Aaaah, bad attachment, sorry. This one should be it.
EDIT 2: Seems like someone here is too stupid to attach the correct file? Here goes...
Please ignore the first two of them, they contain "+++" and "???" strings which I inserted to see if anything was being replaced at all (could have been that only project->GetOutputFilename() returns an empty string).
Maybe I'll get some sleep now...
[attachment deleted by admin]
Urxae:
--- Quote from: thomas on August 15, 2005, 04:59:06 pm ---Also, I noticed that while these macros have the syntax ${NAME}, the ones used during compilation have the syntax $(NAME). Is that intentional?
--- End quote ---
You could try it with ${NAME}, see if that works.
IIRC it shouldn't matter: both should do the exact same thing. If they don't, you might want to file a bug report. And If I didn't Recall Correctly, make that a feature request ;).
thomas:
--- Quote from: Urxae on August 15, 2005, 05:11:36 pm ---You could try it with ${NAME}, see if that works.
--- End quote ---
Did certainly, neither works.
This little modification:
--- Code: ---Manager::Get()->GetMessageManager()->Log("### ReplaceMacros called");
SANITY_CHECK();
Manager::Get()->GetMessageManager()->Log("### past sanity check");
if (buffer.IsEmpty())
return;
Manager::Get()->GetMessageManager()->Log("### buffer not empty");
if (envVarsToo)
ReplaceEnvVars(buffer);
buffer.Replace("${AMP}", "&");
cbProject* project = Manager::Get()->GetProjectManager()->GetActiveProject();
if (project)
{
Manager::Get()->GetMessageManager()->Log("### if branch");
wxFileName fname(project->GetFilename());
buffer.Replace("${PROJECT_FILENAME}", UnixFilename(fname.GetFullName()));
buffer.Replace("${PROJECT_NAME}", project->GetTitle());
buffer.Replace("${PROJECT_DIR}", UnixFilename(project->GetBasePath()));
buffer.Replace("${MAKEFILE}", UnixFilename(project->GetMakefile()));
buffer.Replace("${OUTPUT_FILE}", UnixFilename(project->GetOutputFilename())+"+++");
buffer.Replace("${OUTPUT_DIR}", UnixFilename(wxFileName(project->GetOutputFilename()).GetPath(wxPATH_GET_VOLUME)));
wxString files;
for (int i = 0; i < project->GetFilesCount(); ++i)
files << UnixFilename(project->GetFile(i)->relativeFilename) << " ";
buffer.Replace("${ALL_PROJECT_FILES}", files);
}
else
{
Manager::Get()->GetMessageManager()->Log("### else branch");
--- End code ---
Produces exactly no log output.
So I believe it is pretty certain that the function is never really called. Will submit a bug report.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version