Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Directory separator in project file (.cbp)
MortenMacFly:
--- Quote from: oBFusCATed on August 07, 2012, 05:21:39 pm ---For the macros aren't we saving them as the user have typed them? For example "$(MY_MACRO)/test" is save as is.
--- End quote ---
Huh? I doubt this is. If so, my attempt would be OK. I believe "$(MY_MACRO)/test" would be "$(MY_MACRO)\test" on Windows.
--- Quote from: oBFusCATed on August 07, 2012, 05:21:39 pm ---
--- 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.
--- End quote ---
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.
--- Quote from: Alpha on August 07, 2012, 05:27:29 pm ---?! 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: [...]
--- End quote ---
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:
--- Quote from: MortenMacFly on August 07, 2012, 06:19:37 pm ---Huh? I doubt this is. If so, my attempt would be OK. I believe "$(MY_MACRO)/test" would be "$(MY_MACRO)\test" on Windows.
--- End quote ---
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?
--- Quote from: oBFusCATed on August 07, 2012, 05:21:39 pm ---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.
--- End quote ---
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:
--- Quote from: MortenMacFly on August 07, 2012, 06:19:37 pm ---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.
--- End quote ---
I will see what I can come up with.
MortenMacFly:
--- Quote from: Alpha on August 07, 2012, 07:57:11 pm ---I will see what I can come up with.
--- End quote ---
Forget it for a while and try the attached patch... this is my last attempt... ;D :P
Edit: Patch updated (see more recent post).
MortenMacFly:
--- Quote from: oBFusCATed on August 07, 2012, 06:51:11 pm ---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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version