minor issues about cbp file

[Freem]

I recently have setup a project at savannah.nongnu.org.
Here, an admin told that cbp file should have license in it, like source files. (I never thought about adding a license in a project file, by the way!)

So I tried to add-it, and verify if a change in C::B will let it in the file, but C::B remove it.

This is a very minor issue, or maybe an improvement idea, but it could be interesting if C::B could just modify sections it have to modify.
Another more minor issue (a PEBCAK one in fact) is that if there is a broke in the project file (like plain text out of markup) C::B will not load it, but will not say why or even if it have loaded it.

Those 2 problems are in the latest nightly.

And at last, and totally out of topic, I tried to use C::B with MS Visual Studio 2008 at work (I just can't use efficiently an IDE which can't highlight text similar to the selected one, or is so messy with project options. This is the point which made me remember how user friendly is C::B!). It work nice, but I have found that there is an encoding issue when debugging (debug with GDB).
The nightly used is 7452 if I remember correctly...

[Alpha]

I have another minor issue: when using a dynamic library, there are options to create a custom name for the import library and the definition file.  Any changes made here work during the active session, however, they are not saved in the cbp.

I recently have setup a project at savannah.nongnu.org.
Here, an admin told that cbp file should have license in it, like source files. (I never thought about adding a license in a project file, by the way!)

So I tried to add-it, and verify if a change in C::B will let it in the file, but C::B remove it.

This is a very minor issue, or maybe an improvement idea, but it could be interesting if C::B could just modify sections it have to modify.

Another option would be to have Code::Blocks store any xml comments (<!-- text -->) during the opening of a workspace/project file; then on save, write all stored comments to the top of the respective files.  (File format would be left backwards-compatible.)

[ollydbg]

And at last, and totally out of topic, I tried to use C::B with MS Visual Studio 2008 at work (I just can't use efficiently an IDE which can't highlight text similar to the selected one, or is so messy with project options. This is the point which made me remember how user friendly is C::B!). It work nice, but I have found that there is an encoding issue when debugging (debug with GDB).
The nightly used is 7452 if I remember correctly...

Which encoding issue? Can you be more specific?

I recently have setup a project at savannah.nongnu.org.
Here, an admin told that cbp file should have license in it, like source files. (I never thought about adding a license in a project file, by the way!)
So I tried to add-it, and verify if a change in C::B will let it in the file, but C::B remove it.

I think C::B's cbp file have a "notes" page, you can see it in Right click on your cbp project->Context menu->Properties..->Notes.
So, you can put the license there.

[oBFusCATed]

Or you can use some of your time to provide a patch for setting the license, I doubt it will take you much time

[MortenMacFly]

I wonder how they handle Visual Studio project files - this should be the same problem. Are you sure the guys understood that this is a project file and not a source file?

In the mean time: You can surely use the project notes to add a license as "work-around". This will persists across savings.

[Freem]

I am not sure about the fact he understood that this is a project file
I have sent a reply about that, anyway, but doesn't have reply myself at the moment.
Didn't thought about the "note" space too.

But as I said, it is only a minor issue.

Or you can use some of your time to provide a patch for setting the license, I doubt it will take you much time

I am not sure about the fact I am skilled enough to understand the code of codeblocks.

And at last, and totally out of topic, I tried to use C::B with MS Visual Studio 2008 at work (I just can't use efficiently an IDE which can't highlight text similar to the selected one, or is so messy with project options. This is the point which made me remember how user friendly is C::B!). It work nice, but I have found that there is an encoding issue when debugging (debug with GDB).
The nightly used is 7452 if I remember correctly...

Which encoding issue? Can you be more specific?

Characters are not displayed as they should. I had some dummy characters on some places in reports. Here is an example:

Code

main.cpp
Camera.cpp
f:\copie (2) de camera Š—…\camera\camera.h(14) : error C2143: erreur de syntaxeÿ: absence de '>' avant ';'
Process terminated with status 2 (0 minutes, 5 seconds)
1 errors, 0 warnings (0 minutes, 5 seconds)
 
f:\copie (2) de camera Š—…\camera\Camera.h(14) : error C2143: erreur de syntaxeÿ: absence de '>' avant ';'
Process terminated with status 2 (0 minutes, 5 seconds)
2 errors, 0 warnings (0 minutes, 5 seconds)

As I thought about that, I think I remember that this dumb 'ÿ' have the code 0xFF in ascii...
And the strange characters in file names where added just to verify if it was just a parsing error for 'ÿ', as I thought when writing my last sentence, or a true encoding problem. Usually I never put accentuated letters in things where programming is involved ^^
It should have been "F:\Copie (2) de camera èùà" instead.

I am not used to windows, so if you need other informations about used encoding or something else, please explain quickly how to gather them.
Ah, and I forgot to say that: compiler is VC9, XP pro SP3, and finally I am using C::B 7550 too here.


PS: sorry for the long time before reply, those times I don't have many time to go here, I can not even follow what is happening.

[ollydbg]

Characters are not displayed as they should. I had some dummy characters on some places in reports. Here is an example:

Code

main.cpp
Camera.cpp
f:\copie (2) de camera Š—…\camera\camera.h(14) : error C2143: erreur de syntaxeÿ: absence de '>' avant ';'
Process terminated with status 2 (0 minutes, 5 seconds)
1 errors, 0 warnings (0 minutes, 5 seconds)
 
f:\copie (2) de camera Š—…\camera\Camera.h(14) : error C2143: erreur de syntaxeÿ: absence de '>' avant ';'
Process terminated with status 2 (0 minutes, 5 seconds)
2 errors, 0 warnings (0 minutes, 5 seconds)

As I thought about that, I think I remember that this dumb 'ÿ' have the code 0xFF in ascii...
And the strange characters in file names where added just to verify if it was just a parsing error for 'ÿ', as I thought when writing my last sentence, or a true encoding problem. Usually I never put accentuated letters in things where programming is involved ^^
It should have been "F:\Copie (2) de camera èùà" instead.

I am not used to windows, so if you need other informations about used encoding or something else, please explain quickly how to gather them.
Ah, and I forgot to say that: compiler is VC9, XP pro SP3, and finally I am using C::B 7550 too here.

I suggest you need to follow two rule:
1, use the file/project paths which only contains  English characters, which is (A-Z, a-z and _)
2, remove all the spaces in the file paths.

I think gdb under Windows do not handle them if you have other Unicode characters.

[Freem]

And the strange characters in file names where added just to verify if it was just a parsing error for 'ÿ', as I thought when writing my last sentence, or a true encoding problem. Usually I never put accentuated letters in things where programming is involved ^^

I never use those dumb characters in usual projects, if I should give a regex which can recognize characters I am using in my file names, it would be "[a-z0-9_\.]+"
Spaces, and dumb characters where added to give more indications about the problem.
The original message I had was something like that (but, with different warnings and errors, I just introduced a space to have an error here):

Code

-------------- Build: Debug in Camera ---------------

main.cpp
Camera.cpp
Camera.cpp(86) : error C2039: 'retu'ÿ: n'est pas membre de 'PBCallInfo'
        c:\program files\sybase\powerbuilder 12.0\sdk\pbni\include\pbni.h(278)ÿ: voir la d‚claration de 'PBCallInfo'
Camera.cpp(86) : error C2146: erreur de syntaxeÿ: absence de ';' avant l'identificateur 'rnValue'
Camera.cpp(86) : error C2065: 'rnValue'ÿ: identificateur non d‚clar‚
Camera.cpp(86) : error C2227: la partie gauche de '->SetInt' doit pointer vers un type class/struct/union/g‚n‚rique
        le type est ''unknown-type''
Process terminated with status 2 (0 minutes, 5 seconds)
4 errors, 0 warnings (0 minutes, 5 seconds)
 
Process terminated with status 0 (0 minutes, 6 seconds)
4 errors, 0 warnings (0 minutes, 6 seconds)

As you can see, here, there is a 'ÿ' character, which should not be there.

Here is the result of what Visual Studio give me:

Code

1>------ Début de la génération : Projet : camera, Configuration : Debug Win32 ------
1>Compilation en cours...
1>Camera.cpp
1>.\Camera.cpp(86) : error C2039: 'retu' : n'est pas membre de 'PBCallInfo'
1>        c:\program files\sybase\powerbuilder 12.0\sdk\pbni\include\pbni.h(278) : voir la déclaration de 'PBCallInfo'
1>.\Camera.cpp(86) : error C2146: erreur de syntaxe : absence de ';' avant l'identificateur 'rnValue'
1>.\Camera.cpp(86) : error C2065: 'rnValue' : identificateur non déclaré
1>.\Camera.cpp(86) : error C2227: la partie gauche de '->SetInt' doit pointer vers un type class/struct/union/générique
1>        le type est ''unknown-type''
1>Le journal de génération a été enregistré à l'emplacement "file://f:\camera\Camera\Debug\BuildLog.htm"
1>camera - 4 erreur(s), 0 avertissement(s)
========== Génération : 0 a réussi, 1 a échoué, 1 mis à jour, 0 a été ignoré ==========

I think it could show two problems, and maybe the second one is related to the first one:
_ first: there is a 'ÿ' character, which seem to separate location of the problem and it's description. (it is always before the ':' and after the thing which made the problem)
_ second: the encoding is not well detected, causing stupid characters to not be correctly shown. It may be related to the 'ÿ' character, because as far as I know, encoding detection rely on statistics about character found. A dumb character could false the detection.

And it is not at debug time, but compile time. It is not gdb which is used here, but "cl.exe"

Note: I used terms "seem", "may", "could" because I am sure of nothing. I only make suppositions for something I think is really small problem. Error and warning detection is not wrong, and if I just have to forget a 'ÿ' character (which is not used in french) it don't give me big troubles.

[oBFusCATed]

Why are you using internationalized version of cl?
C::B is meant to work only with English version of the compilers, as far as I know.

Can you try a version of the cl which returns English only messages?

[Freem]

I only have this version at work, and don't use VC at home.
And I have to admit that I never used an internationalized version of GCC (or if I did, I probably have quickly returned to english and don't remember that)

[Alpha]

Another option would be to have Code::Blocks store any xml comments (<!-- text -->) during the opening of a workspace/project file; then on save, write all stored comments to the top of the respective files.  (File format would be left backwards-compatible.)

Proof of concept (for *.cbp's):

Code

Index: src/sdk/projectloader.cpp
===================================================================
--- src/sdk/projectloader.cpp	(revision 7696)
+++ src/sdk/projectloader.cpp	(working copy)
@@ -256,6 +256,21 @@
 //        wxString minor = version->Attribute("minor");
     }
 
+    pMsg->DebugLog(_T("Scanning project for comments..."));
+    TiXmlNode* child = 0;
+    while(child = doc.IterateChildren(child))
+    {
+        if(child->Type() == TiXmlNode::TINYXML_COMMENT)
+        {
+            m_pProject->fileComments << wxString::FromAscii(child->Value()) << wxT("\n");
+        }
+    }
+    if(m_pProject->fileComments.Right(1) == wxT("\n"))
+    {
+        m_pProject->fileComments.Truncate(m_pProject->fileComments.Length() - 1);
+    }
+
     pMsg->DebugLog(wxString(_T("Done loading project in ")) << wxString::Format(_T("%d"), (int) sw.Time()) << _T("ms"));
     return true;
 }
@@ -1077,6 +1092,10 @@
     TiXmlDocument doc;
     doc.SetCondenseWhiteSpace(false);
     doc.InsertEndChild(TiXmlDeclaration("1.0", "UTF-8", "yes"));
+    if(!m_pProject->fileComments.IsEmpty())
+    {
+        doc.InsertEndChild(TiXmlComment(m_pProject->fileComments.ToAscii()));
+    }
     TiXmlElement* rootnode = static_cast<TiXmlElement*>(doc.InsertEndChild(TiXmlElement(ROOT_TAG)));
     if (!rootnode)
         return false;
Index: src/include/cbproject.h
===================================================================
--- src/include/cbproject.h	(revision 7696)
+++ src/include/cbproject.h	(working copy)
@@ -683,6 +683,8 @@
           */
         virtual FilesList& GetFilesList(){ return m_Files; }
 
+        wxString fileComments;
+
     private:
         void Open();
         void ExpandVirtualBuildTargetGroup(const wxString& alias, wxArrayString& result) const;

This is probably not the best method, but it does work.

[thomas]

Oh my... that again.

The mere fact that one can open an undocumented, machine-generated and machine-read, proprietary file in a text editor does not mean it's ok to do it, nor that it should be supported. There's been no week ever since I thought using XML was a brilliant idea during which I've not regretted that.

Project files, like the config file, are not meant to be edited by hand. Adding explicit support for making edits persistent is opening a can of worms. Heck, I've even considered ROT13 encoding config and projects at some point just because some smart alec came up with "but it's XML, it is meant to be edited" every couple of months. Even if you were Tim Bray, I'd show you the middle finger for that, because no matter what, sooner or later someone will fuck up his project file with a manual edit, and again people will spend their time trying to figure why Code::Blocks scrambles files.

If the admins at Savannah are unable to deduct a project files's license from the project's license or from what's in the LICENSE file, I'm truly sorry for them.

Now if there is truly need to store license information in the project file, add a tab "project info" to the project properties dialog, and put text edit fields such as "author", "license", "checkout URL", whatever, into that tab. Put the properly quoted info into the project file using the intended API in a well-defined way. Add a separate section, if you deem this appropriate.

That said, I'll revert any commit I see which makes manual edits persistent.

[MortenMacFly]

That said, I'll revert any commit I see which makes manual edits persistent.

I agree with Thomas here.

Actually the change is quite simple: Modify the project page that shows the project notes and extend it as you like, then provide a patch. However, I still believe that the notes page *is* already the right place to put license info, if needed and it *is* persisted.

[Alpha]

Thank you for pointing that out.  I will often just pursue whatever goal I happen to have an idea about at the time; I think I need to work harder at restraining myself long enough to consider what I am actually doing .

I have another minor issue: when using a dynamic library, there are options to create a custom name for the import library and the definition file.  Any changes made here work during the active session, however, they are not saved in the cbp.

However, am I correct in my assumption that it is OK for me to work on adding this to the file format?