Index: src/sdk/globals.cpp
===================================================================
--- src/sdk/globals.cpp (revision 8133)
+++ src/sdk/globals.cpp (working copy)
@@ -201,6 +201,11 @@
return result;
}
+wxString NativeToUnix(const wxString& filename)
+{
+ wxFileName fname(filename);
+ return fname.GetFullPath(wxPATH_UNIX);
+}
void QuoteStringIfNeeded(wxString& str)
{
Index: src/sdk/projectloader.cpp
===================================================================
--- src/sdk/projectloader.cpp (revision 8133)
+++ src/sdk/projectloader.cpp (working copy)
@@ -1175,7 +1175,7 @@
{
wxFileName fname(outputFileName);
fname.ClearExt();
- outputFileName = fname.GetFullPath();
+ outputFileName = fname.GetFullPath(wxPATH_UNIX);
}
if ( (prefixPolicy == tgfpPlatformDefault)
@@ -1197,7 +1197,7 @@
if (!outputFileNameWOPrefix.IsEmpty())
{
fname.SetFullName(outputFileNameWOPrefix);
- outputFileName = fname.GetFullPath();
+ outputFileName = fname.GetFullPath(wxPATH_UNIX);
}
}
}
@@ -1207,19 +1207,19 @@
if (target->GetTargetType() == ttDynamicLib)
{
if (target->GetDynamicLibImportFilename() != _T("$(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME)"))
- outnode->SetAttribute("imp_lib", cbU2C(target->GetDynamicLibImportFilename()));
+ outnode->SetAttribute("imp_lib", cbU2C(NativeToUnix(target->GetDynamicLibImportFilename())));
if (target->GetDynamicLibImportFilename() != _T("$(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME)"))
- outnode->SetAttribute("def_file", cbU2C(target->GetDynamicLibDefFilename()));
+ outnode->SetAttribute("def_file", cbU2C(NativeToUnix(target->GetDynamicLibDefFilename())));
}
outnode->SetAttribute("prefix_auto", prefixPolicy == tgfpPlatformDefault ? "1" : "0");
outnode->SetAttribute("extension_auto", extensionPolicy == tgfpPlatformDefault ? "1" : "0");
if (target->GetWorkingDir() != _T("."))
- AddElement(tgtnode, "Option", "working_dir", target->GetWorkingDir());
+ AddElement(tgtnode, "Option", "working_dir", NativeToUnix(target->GetWorkingDir()));
if (target->GetObjectOutput() != _T(".objs"))
- AddElement(tgtnode, "Option", "object_output", target->GetObjectOutput());
+ AddElement(tgtnode, "Option", "object_output", NativeToUnix(target->GetObjectOutput()));
if (target->GetDepsOutput() != _T(".deps"))
- AddElement(tgtnode, "Option", "deps_output", target->GetDepsOutput());
+ AddElement(tgtnode, "Option", "deps_output", NativeToUnix(target->GetDepsOutput()));
}
if (!target->GetExternalDeps().IsEmpty())
AddElement(tgtnode, "Option", "external_deps", target->GetExternalDeps());
@@ -1377,7 +1377,7 @@
ProjectFile* f = pfa[i];
FileType ft = FileTypeOf(f->relativeFilename);
- TiXmlElement* unitnode = AddElement(prjnode, "Unit", "filename", f->relativeFilename);
+ TiXmlElement* unitnode = AddElement(prjnode, "Unit", "filename", NativeToUnix(f->relativeFilename));
if (!f->compilerVar.IsEmpty())
{
wxString ext = f->relativeFilename.AfterLast(_T('.')).Lower();
@@ -1404,7 +1404,7 @@
AddElement(unitnode, "Option", "weight", f->weight);
if (!f->virtual_path.IsEmpty())
- AddElement(unitnode, "Option", "virtualFolder", f->virtual_path);
+ AddElement(unitnode, "Option", "virtualFolder", NativeToUnix(f->virtual_path));
// loop and save custom build commands
for (pfCustomBuildMap::iterator it = f->customBuild.begin(); it != f->customBuild.end(); ++it)
Index: src/include/globals.h
===================================================================
--- src/include/globals.h (revision 8133)
+++ src/include/globals.h (working copy)
@@ -181,6 +181,7 @@
extern DLLIMPORT void AppendArray(const wxArrayString& from, wxArrayString& to);
extern DLLIMPORT wxString UnixFilename(const wxString& filename);
+extern DLLIMPORT wxString NativeToUnix(const wxString& filename);
extern DLLIMPORT void QuoteStringIfNeeded(wxString& str);
/// Escapes spaces and tabs (NOT quoting the string)
Try this patch:This is a nice work, however, it is not that easy, and therefoe this patch is incomplete:
if (platform::windows)
{
bool unc_name = result.StartsWith(_T("\\\\"));
while (result.Replace(_T("/"), _T("\\")))
;
while (result.Replace(_T("\\\\"), _T("\\")))
;
if (unc_name)
result = _T("\\") + result;
else // THIS PART IS NEW!!!
{
while (result.Replace(_T("\\"), _T("/")))
;
}
}
Seems like most practical thing to do is to use:That's how it is now and what was complained. ::)
- Relative paths as much as possible
- Automatically convert the directory separator.
Seems like most practical thing to do is to use:That's how it is now and what was complained. ::)
- Relative paths as much as possible
- Automatically convert the directory separator.
If that's OK we don't need to change anything. ???
If I understand the post correctly the conversion should only be done if we call any external programs, like compiler, linker etc. , but internally (especially in project- and workspace-files) use the same syntax on all platforms.Ah, OK... ::)
This might probaly lead to problems with (windows-) parameters that get saved in the project-file, because they also use a slash in many (most?) cases.That what my approach tries to avoid: I only change path's we can change safely w/o interfering with tools not supporting it (although I have to admit that I never tried to compile a file using MSVC with this patch applied). For Windows, you cannot easily convert all back-slashes to slashes. For this I see no way - just consider this command line:
...here comes an alternative patch accordingly.For the record: Both patches have serious side-effects. The most serious one is that having these applied and using macros related to one of these path's on Windows will break the console commands, as e.g.
(Very late reply :), but) I was reading/writing quickly and missed it.
- Why didn't you use the existing UnixFilename method?
In my opinion, anything saved to a .cbp (or .workspace) that has an internal representation as a path or a file name should be saved with "/" and converted (in memory) to the native format on load.Well and that is the problem: You don't know, if pre- or post-build steps (for example) are a path or if a "\" or "/" is part of a macro etc.. So it is error-prone. There is no such easy thing like "convert on load" without making mistakes. Only the user knows how (s)he would like to interpret / setup such things. So its best to leave it as setup by the user IMHO.
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.
Well and that is the problem: You don't know, if pre- or post-build steps (for example) are a path or if a "\" or "/" is part of a macro etc.. So it is error-prone.
(Attempting conversion of anything else - command line parameters, pre/post-build steps - would both be unwise and unlikely to work reliably.)?! 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 (http://wiki.codeblocks.org/index.php?title=Project_file), the variables that are saved in:
<Script file="" />
<Option output="default" prefix_auto="1" extension_auto="1" />
<Option working_dir="." />
<Option object_output=".objs" />
<Option deps_output=".deps" />
<Option external_deps="" />
<Option additional_output="" />
<Option host_application="" />
<Add directory="" />
<Unit filename="BuildScripts/config.script"></Unit>
<Option virtualFolder="" />
There is no such easy thing like "convert on load" without making mistakes.For these specific cases (or most of them), Code::Blocks already uses a "convert on load" (this is how it accepts, for example, files with Linux paths on a Windows computer) - which is what caused the problem listed in the first post, it is not standardized which format they save back to.
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.
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.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.
?! 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 (http://wiki.codeblocks.org/index.php?title=Project_file), 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.
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?
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.
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.
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 :P
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.
Forget it for a while and try the attached patch... this is my last attempt... ;D :P...ooops: Tiny error in the patch - corrected version here:
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.
...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.
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);