Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Directory separator in project file (.cbp)
MortenMacFly:
--- Quote from: MortenMacFly on July 19, 2012, 08:54:17 am ---...here comes an alternative patch accordingly.
--- End quote ---
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.
"copy myfoldel/fo/bar .." won't work on Windows. So either there is a context and platform sensitive way to convert the path correctly or it remains as it is.
As I don't see a way w/o much and error-prone effort for the first choice I'm afraid the second is the way to go. ::)
Alpha:
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. (Attempting conversion of anything else - command line parameters, pre/post-build steps - would both be unwise and unlikely to work reliably.)
This would remain completely backwards compatible, and deal with enough cases to (mostly) take care of the original problem: sharing the same project file between Windows and Linux.
--- Quote from: MortenMacFly on July 19, 2012, 08:28:01 am ---
* Why didn't you use the existing UnixFilename method?
--- End quote ---
(Very late reply :), but) I was reading/writing quickly and missed it.
MortenMacFly:
--- Quote from: Alpha on August 07, 2012, 03:39:33 pm ---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.
--- End quote ---
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.
oBFusCATed:
--- Quote from: MortenMacFly on August 07, 2012, 05:04:24 pm ---BTW: And a partial solution makes no sense, too - because then you still have differences.
--- End quote ---
Yes, but they will be far less. And adding a file to the project won't cause conflicts.
For the macros aren't we saving them as the user have typed them? For example "$(MY_MACRO)/test" is save as is.
My opinion is that we must not modify anything the users has typed with the keyboard and we should modified anything entered by a paths-like dialog.
So the "other options" in the linker/compiler or the "post/pre build steps" won't be changed, they will be save as entered.
The paths in the search paths section of the settings will be save in unix/dos format (doesn't matter which, but I prefer unix of course:) ).
And if we want to preserve the cross platform support we can provide a marco to convert a path to native format, which can be used in the non-converted sections.
It will be a little tedious to setup, but it will be explicit and not work auto magically.
p.s. this is the second time I post similar answer, the first time the post gone missing for some strange reason...
Alpha:
--- Quote from: MortenMacFly on August 07, 2012, 05:04:24 pm ---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.
--- End quote ---
--- Quote from: Alpha on August 07, 2012, 03:39:33 pm ---(Attempting conversion of anything else - command line parameters, pre/post-build steps - would both be unwise and unlikely to work reliably.)
--- End quote ---
?! 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:
--- Code: ---<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="" />
--- End code ---
--- Quote from: MortenMacFly on August 07, 2012, 05:04:24 pm ---There is no such easy thing like "convert on load" without making mistakes.
--- End quote ---
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.
(Oops, our posts crossed...)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version