AutoVersioning Plugin

[JGM]

suggestions :
 - don't use defines (bad, preprocessor and ancient C shit)
 - use static const int or something like that
 - put them in a special namespace to avoid collisions

Nice suggestion, I will do it. 

But C stills very powerful today

Edit:

Men! the development of this simple plugin is taking me more than I expected. I went in to problems with a crappy library of csv that I Implemented.   :x

The problem that I have was when uninstalling the plugin, produced a crash. It seem that the library that I made was having some pointer problems. Now i will implement the plugin using wxFileConfig to store the version variables for producing the header file. It should not produce complications now 

[tiwag]

suggestions :
 - don't use defines (bad, preprocessor and ancient C shit)
 - use static const int or something like that
 - put them in a special namespace to avoid collisions

don't be too harsh please 

this C shit is still widely used in the embedded world
with which I'm working daily.  :shock:

and i can assure you, i don't feel sucked myself because of that 

[JGM]

this C shit is still widely used in the embedded world
with which I'm working daily.  :shock:

Wow you program embedded systems!. I'm fascinated on learning this subject, is the real programming world, directly managing the hardware without OS. Cool! 

Well following the recommendations of killerbot now the output is this one:

Code

namespace AutoVersion{
	
	//Date Version Types
	static long DATE_VERSION = 29;
	static long MONTH_VERSION = 06;
	static long YEAR_VERSION = 2007;
	static double UBUNTU_VERSION_STYLE = 7.06;
	
	//Standard Version Types
	static long MAJOR_VERSION = 1;
	static long MINOR_VERSION = 0;
	static long BUILD_NUMBER = 0;
	static long REVISION = 0;
	
	//Miscellaneous Version Types
	static long BUILDS_COUNT = 1;
	#define RC_FILEVERSION 1,0,0,0
	#define RC_FILEVERSION_STRING "1, 0, 0, 0\0"
	static char FULLVERSION_STRING[] = "1.0.0.0";
	
}

I fixed the problem I was Having while uninstalling the plugin, but now all is working right. Now i will really implement the updating functions. :shock:

[JGM]

I finished the plugin, check the first post to download the source!

[JGM]

I have found a freaking bug,

The program is writing into the version.h "%" signs instead of the actual numbers from the version.ini.

This is the problem:

Code

        static double UBUNTU_VERSION_STYLE = %.07; //here also?
	
	//Standard Version Types
	static long MAJOR_VERSION = %;
	static long MINOR_VERSION = %;
	static long BUILD_NUMBER = %;
	static long REVISION = %;
	
	//Miscellaneous Version Types
	static long BUILDS_COUNT = %;

I don't know how this occurs :oops:. I will hunt this bug. It should be something silly.

[killerbot]

suggestions :
 - don't use defines (bad, preprocessor and ancient C shit)
 - use static const int or something like that
 - put them in a special namespace to avoid collisions

don't be too harsh please 

this C shit is still widely used in the embedded world
with which I'm working daily.  :shock:

and i can assure you, i don't feel sucked myself because of that 

I do embedded stuff too, but luckily already C++, my C days are a while ago now ;-)

But also in C: you can have static const, which is still better then defines.
I think C99 also has namespaces but I am not sure though. But then your embedded compiler needs to be rather up to date ...

[JGM]

Fixed the problem,

It seems that the wxString operator<< have a bug handling long variables. First I was using some wxString Printf function to acquire the version functions from the ini file to convert them from long to string and then switched to just put the long values in the wxString<< operator. But now back again to Printf and is working fine.

If somebody have suggestions please post them 

Updated again the attachment in the first post to have this update.

[raph]

Could you add an option to detect the revision number of the project and put it in version.h (like cb does)?
It would be nice to have autorevision's functionality built into codeblocks

[JGM]

Could you add an option to detect the revision number of the project and put it in version.h (like cb does)?
It would be nice to have autorevision's functionality built into codeblocks

Theres already a variable declared "static long REVISION = 0;", it increments randomly up to 30 10 (now is editable using the scheme editor) every time some file in the project has been modified. Thats what you mean :?: Or is something else?

[raph]

No, I mean revision number of a version control system as codeblocks does it with svn (see sourcecode of autoversion in codeblocks_source_dir/src/build_tools/autorevision how it can be parsed).
Every time you do a "svn commit", the revision number is increased.
This guarantees, that there really are changes to the project that justify an incrementation of the version number and makes the project's version information much more meaningful.

[JGM]

No, I mean revision number of a version control system as codeblocks does it with svn (see sourcecode of autoversion in codeblocks_source_dir/src/build_tools/autorevision how it can be parsed).
Every time you do a "svn commit", the revision number is increased.
This guarantees, that there really are changes to the project that justify an incrementation of the version number and makes the project's version information much more meaningful.

I get it now! Is a great Idea 

The only problem is that I never had used SVN or CVS  :oops: don't know how the whole thing works  :shock:
But I'm already reading the online svn book and I'm getting the concept  . Sorry for my ignorance . When I read the basic concepts of svn and how to use it I will implement this. Is a nice way for me to start  using svn.

I looked the source code used on codeblocks for parsing the svn command xml output and it looks pretty strait forward to implement on the plugin.

I will put a check box that says "svn enabled?" and if marked then generate an SVN_REVISION variable. I don't know if also I should add a field that points to the directory where the actual svn configuration files reside in the project. I will look into this.

[JGM]

Could you add an option to detect the revision number of the project and put it in version.h (like cb does)?
It would be nice to have autorevision's functionality built into codeblocks

Done! Finished adding this feature. Check the first post for screenshot and download 

[mp]

I can't compile plug in.

Code

avSvnRevision.cpp:: In function `bool QuerySvn(const std::string&, std::string&, std::string&)':
avSvnRevision.cpp:32: error: 'class TiXmlElement' has no member named 'GetText'
avSvnRevision.cpp:33: error: 'class TiXmlElement' has no member named 'GetText'

AutoVersioning.cpp:27: error: `EVT_COMPILER_STARTED' was not declared in this scope
AutoVersioning.cpp:28: error: expected `}' before "EVT_COMPILER_FINISHED"
AutoVersioning.cpp:28: error: expected `,' or `;' before "EVT_COMPILER_FINISHED"
AutoVersioning.cpp:30: error: expected declaration before '}' token

Could You provide compiled version?

[JGM]

I can't compile plug in.

Code

avSvnRevision.cpp:: In function `bool QuerySvn(const std::string&, std::string&, std::string&)':
avSvnRevision.cpp:32: error: 'class TiXmlElement' has no member named 'GetText'
avSvnRevision.cpp:33: error: 'class TiXmlElement' has no member named 'GetText'

AutoVersioning.cpp:27: error: `EVT_COMPILER_STARTED' was not declared in this scope
AutoVersioning.cpp:28: error: expected `}' before "EVT_COMPILER_FINISHED"
AutoVersioning.cpp:28: error: expected `,' or `;' before "EVT_COMPILER_FINISHED"
AutoVersioning.cpp:30: error: expected declaration before '}' token

Could You provide compiled version?

I got to update the events handling on the plugin because that methods are deprecated in the new codeblocks revision.

What operating system are you using? A compiled version depends on the actual version of codeblocks that you are using and and the wxWidgets library to work.

Is weird that error on the Tiny Xml Class. I don't got that error, may be you are using an old version or newer than I have. I will check this.

If you can provide the actual revision of codeblocks that you are using will be of help to diagnostic the problem.

[killerbot]

maybe it's because of the way that person used your code. I just had a look at avSvnRevision.h/cpp

-> include "tinyxml/tinystr.h", the fact that you specify a subdir, could be the party pooper.

Some advice to the code of avSvnRevision.h

- never ever put using namespace in a header file
- the include's of tinyxml are NOT needed here -> you don't do anything with them in the header, so they do NOT belong there
- the include of cstdio does not belong here, inside the header you use NOTHING from that header file

Core new code suggestion :

Code

#include <string>

bool QuerySvn(const std::string& workingDir, std::string& revision, std::string& date);

I also had a look at the corresponding cpp file :
here you should put the includes of :
  - cstddio.h
  - tinyxml.h (probably tinystr.h is not needed) (suggestion : don't put an extra dir in front, just add the dir to your include paths of the project

Things that can be removed from this file are :
  - the include of wx.h [you don't use anything from wxwidgets in this code, aside use the headers with the things you actually use from wx, don't just include a monster of a header file]
  - remove the macro (by the way don't use macros, they are f*** BAD, use a function, a template, ...], but in this case the macro is not used

Other suggestions :
  - be const correct and scope limiting : your TinyXmlElement's are const --> put that in the code, and limit their scope, also make use of handle, it will simplify your code

Code

  TiXmlHandle Handle(&doc);
  if(const TiXmlElement* e =  Handle.FirstChildElement("entry").FirstChildElement("commit").ToElement())
  {
    revision = e->Attribute("revision") ? e->Attribute("revision") : "";
    const TiXmlElement *d = e->FirstChildElement("date");
    if(d && d->GetText())
    {
                date = d->GetText();
    }
  }

  - don't use memset when it is not needed, you can easily replace :

Code

        char buf[16384];
        memset(buf, 0, 16384);

by :

Code

        char buf[16384] = {'\0'};

  - try to avoid magic numbers like '16384' and '16384' and '16383, for sure they are all related, but are they ..., put that magic number in a const variable (no define !!!)

I hope you find these tips and code corrections useful. I didn't look at the other source files, I just took a peek for this one wrt compile problem.
Cheers.