Minor enhancement of "External dependencies" GUI

[MortenMacFly]

I would like to make a suggestion for a minor GUI enhancement (time to run away... ;-)):
Under project properties -> targets -> dependencies -> external dependency files it would be very nice if a double click would open the edit dialog for this dependency. Such as it is e.g. under build options for the libraries. The same request I would like to state for "additional output files" (which is on the same dialog). This would speed-up changing things a bit.
Morten.

[thomas]

1994 has it.

[MortenMacFly]

1994 has it.

...your make my day.
Thanks a lot... Compiling 1994 now...
Morten.
Ps.: Uh, compiling the past (1994) - I realise that soon we hit the 2000, and then 2006 and then - the future! :lol:

[mandrav]

Once, Thomas had this idea that revision 2000 (or was it 2006?) could be our RC3 release.
But at the rate we 're committing, this could move a millenium beyond or so.

[MortenMacFly]

But at the rate we 're committing, this could move a millenium beyond or so.

...hehe. I hope this doesn't mean you stop committing. :shock: :lol:

BTW: I tried 1994 now - it works. And I saw that the changes were a only 2-liner... that's cool.
I have to change around 40 project files in this way because the names of libraries have changed so this will certainly increase my productivity, really!
Morten.

[thomas]

I have to change around 40 project files in this way because the names of libraries have changed so this will certainly increase my productivity, really!

Lol, you know I am normally strictly against doing such things. But changing the dependency names in 40(!) projects really justifies running a global search/replace on the project files using sed or a text editor or whatever... :lol:

You know, sed does that as a one-liner...

[MortenMacFly]

You know, sed does that as a one-liner...

Well, it's not so easy, because it's target dependend. I got debug-libs for the external dependencies so I want really only the debug-target-dependencies to be changed. A search & replace would also change all the other targets as well. Furthermore I trust C::B more than a search & replace tool. And I am addicted to GUIs. :lol:
Morten.

[thomas]

Changing 40 projects manually one by one will take you 60-70 minutes (estimated).

You could probably write a TinyXML-based application which selectively replaces that one one node (in the respective target) in less than 10 minutes. That would be a lot faster, less annoying, and just as safe.
If there is a lot of work that is outright annoying and stupid like this, then I always say "Hey, what do I have a computer for!"

[MortenMacFly]

You could probably write a TinyXML-based application which [...]

Too late, I've finished by now. :?
Morten.

[thomas]

What a shame... something like this would probably have done it:

Code Select Expand


#include <stdio.h>
#include "tinyxml/tinystr.h"
#include "tinyxml/tinyxml.h"

int main(int argc, char** argv)
{

TiXmlDocument doc(argv[0]);

TiXmlElement *build = doc.FirstChildElement( "CodeBlocks_project_file")->FirstChildElement( "Project")->FirstChildElement( "Build");

if(!build)
return -1;

TiXmlElement *target = 0;

while(target = (TiXmlElement*) build->IterateChildren("Target", target))
{
if(target->Attribute("title") && !strcmp(target->Attribute("title"), "debug"))
{
TiXmlElement *opts = 0;
while(opts = (TiXmlElement*) target->IterateChildren("Option", opts))
{
if(opts->Attribute("external_deps") && !strcmp(opts->Attribute("external_deps"), "oldLibraryName"))
opts->SetAttribute("external_deps", "newLibraryName");
}
}
}

doc.SaveFile();

return 0;
}
I haven't tried whether it even compiles, might be there are a couple of typos in it, but you get the idea...

[MortenMacFly]

What a shame... something like this would probably have done it: [...]

<comic_speech> Grmbl! </comic_speech>
Well... at least I know now for the next time. I also note that I should have a look at TinyXml. Looking at this code-snippet I guess I understand why you are using it. It hardly could be any easier.
Morten.

[thomas]

Of course a *real* application would have to do a few more sanity checks, but since Code::Blocks works fine with those files, we know that they are in a sane state.

Even then, TinyXML makes XML a piece of cake

[thomas]

Once, Thomas had this idea that revision 2000 (or was it 2006?) could be our RC3 release.
But at the rate we 're committing, this could move a millenium beyond or so.

Too late now, I just committed rev. 2000
We'll have to wait for revision 2222 for RC3 :lol: