Directory separator in project file (.cbp)

[MortenMacFly]

For the macros aren't we saving them as the user have typed them? For example "$(MY_MACRO)/test" is save as is.

Huh? I doubt this is. If so, my attempt would be OK. I believe "$(MY_MACRO)/test" would be "$(MY_MACRO)\test" on Windows.

BTW: And a partial solution makes no sense, too - because then you still have differences.

Yes, but they will be far less. And adding a file to the project won't cause conflicts.

Why wouldn't it? If you add a file on Windows and save creates a different file when adding a file on Linux and save - that's what I experienced with C::B for decades now and that's what I wanted to fix.

?!  I was only suggesting using this on variables that Code::Blocks already knows are guaranteed to only be paths or file names.  From Project file format, the variables that are saved in: [...]

I'm afraid this is not entirely true. For example, the output file and object_output can have macros.

Well - let me suggest another approach: Use my patch, modify it the way you think it is correct and re-send. I'll try with some of my projects that make heavy macros usage and report back. I could also think of at least one thing: Definitely the unit files cause most conflicts and diffs - so if its just for them as an interim-step I am fine.

Why I am so sceptic is that the errors I got were really frustrating, because for example copy operations based on macros that used the TARGET_OUTPUT_FILE macro (or alike) were suddenly no longer working causing strange effects with my projects because files were not updated as they should have been. This is exactly the side-effects I meant you don't think off in the first place. And btw: The error message was not highlighted, so it took me a while. :-(

[oBFusCATed]

Huh? I doubt this is. If so, my attempt would be OK. I believe "$(MY_MACRO)/test" would be "$(MY_MACRO)\test" on Windows.

My thought was the we're not expanding the marcos before saving the file, so what are the problems if we always save them in unix format?
C::B already does the conversion if the file have been saved on unix, doesn't it?

Why wouldn't it? If you add a file on Windows and save creates a different file when adding a file on Linux and save - that's what I experienced with C::B for decades now and that's what I wanted to fix.

I think we misunderstand each other.
What I was telling is that the most conflicts happen in the files added to the project, so a partial solution will minimize the problem.
You have said it won't.

[Alpha]

Well - let me suggest another approach: Use my patch, modify it the way you think it is correct and re-send. I'll try with some of my projects that make heavy macros usage and report back. I could also think of at least one thing: Definitely the unit files cause most conflicts and diffs - so if its just for them as an interim-step I am fine.

I will see what I can come up with.

[MortenMacFly]

I will see what I can come up with.

Forget it for a while and try the attached patch... this is my last attempt... ;D

Edit: Patch updated (see more recent post).

[MortenMacFly]

What I was telling is that the most conflicts happen in the files added to the project, so a partial solution will minimize the problem.

Yes, but whats the point in "minimising" here? Either it is the same (which would be nice!) or not. But if you are talking about SVN conflicts - I agree.

[MortenMacFly]

Forget it for a while and try the attached patch... this is my last attempt... ;D

...ooops: Tiny error in the patch - corrected version here:

[oBFusCATed]

But if you are talking about SVN conflicts - I agree.

Yes, the whole problem is related to SVN/VCS conflicts, as the files are not meant to be edited by humans anyway and if VCS is not used the path separator won't be a problem.

[MortenMacFly]

...ooops: Tiny error in the patch - corrected version here:

BTW - with this patch I got another side-effect: CC does not work well anymore and mixes files. That's exactly what I am talking about with undesired side-effects.

However, I've fixed this in my local copy already. It was actually a bad interface in CC.

[Alpha]

Try this patch.

[oBFusCATed]

Seem this is reported as bug, once again. See https://sourceforge.net/p/codeblocks/tickets/36/

[Jenna]

This seems to affect only libraries whitch contain paths.
See my comment: https://sourceforge.net/p/codeblocks/tickets/36/#7e28

[Jenna]

Can you test this patch ?

Code Select Expand

commit b0baeda27eb28cc1e4b9652b6f49b47d8d1e9d16
Author: Jens Lody <jens@codeblocks.org>
Date:   Mon Aug 25 09:31:09 2014 +0200

    * fix for bug #36 Path slashes in project file flip on save between windows and nix

Index: src/sdk/projectloader.cpp
===================================================================
--- src/sdk/projectloader.cpp
+++ src/sdk/projectloader.cpp
@@ -1404,7 +1404,7 @@

         node = AddElement(tgtnode, "Linker");
         AddArrayOfElements(node, "Add", "option",    target->GetLinkerOptions());
-        AddArrayOfElements(node, "Add", "library",   target->GetLinkLibs());
+        AddArrayOfElements(node, "Add", "library",   target->GetLinkLibs(), true);
         AddArrayOfElements(node, "Add", "directory", target->GetLibDirs(), true);
         if (node->NoChildren())
             tgtnode->RemoveChild(node);
@@ -1468,7 +1468,7 @@

     node = AddElement(prjnode, "Linker");
     AddArrayOfElements(node, "Add", "option",    m_pProject->GetLinkerOptions());
-    AddArrayOfElements(node, "Add", "library",   m_pProject->GetLinkLibs());
+    AddArrayOfElements(node, "Add", "library",   m_pProject->GetLinkLibs(), true);
     AddArrayOfElements(node, "Add", "directory", m_pProject->GetLibDirs(), true);
     if (node->NoChildren())
         prjnode->RemoveChild(node);


[Jenna]

I tested it on linux and windows 7 with relative and absolute paths (including drive-letter on win) and decided to commit it in svn r9859 .

[oBFusCATed]

Thanks...