Checking TivaWare version programmatically

I don't think there is a way to do that.

What would your application do differently based on the version?

Robert

Hi Robert,

Thank you for your reply.

I just want to be able to determine what build environment was used to build a running application in order to be able to rebuild the exact same software in case of situation when I need to reproduce and debug some problems.

Thank you,

Peter A.

Hi Peter,

Is there anything wrong with just defining it yourself? Maybe in some header file somewhere in your project?

Cheers,
Bryan

Does not seem like a very reliable way of doing that when code can be build on many machines. If I do it myself and store the definition in version control system anyone in the team can check it out and build it on his machine, which might have any version of TivaWare installed. If assumed (defined) version is different from the actual one it will never be detected.
Does not seem like a big deal if everything is fine. But when you are trying to reproduce a bug and not know what build environment produced it you might end up testing all possible combinations. It would be much easier to simply know exactly and be sure that the information is correct.

Peter Adamus said:

I just want to be able to determine what build environment was used to build a running application in order to be able to rebuild the exact same software in case of situation when I need to reproduce and debug some problems.

Laudable goal.

This is one of the things revision control systems are good for. Every build (or at least every build that could end up on a released unit) should have its own release number and be 'tagged' in the RCS so it can be easily found and extracted.

If you store in the RCS frequently during development (and I recommend it) then it's also easy to backtrack modifications.

The RCS should contain your libraries and your own source. I include the binaries as well since this lets me extract past versions w/o the necessity of compiling. Ideally you would include you compiler and other build tools, I'm not sure many manage that ideal.

If you're already storing the library so you can extract to re-compile against an RCS is actually probably easier.

Robert

Chuck Davenport said:

With that said, I also understand the request for such a function

Yep, just trying to deal with the stated issue. Having that info immediately readable might be useful in some situations (although I'm not convinced it's a significant improvement over the revision number since there is a simple mapping from revision number to library version).

Chuck Davenport said:

In many cases, the build environments are ghosted to a build maching or hard drive that is then preserve for recreating the same environment down the road if needed for legacy product support.

I know of such. The problem (besides getting IT to allow it) is a number of compilers are actively hostile to it^*. They incorporate technology to prevent you from running the compiler (such as Flex)  so the VM may run but that is insufficient to ensure the build environment is successful.

Robert

* - TI is one of the offenders here, I just spent several days doing a simple transfer of license between machines.

Hi Chuck, Robert
Thank you very much for the responses. I will try to improve usage of our RCS and I greatly appreciate the request for adding this functionality. I believe that it will be the most reliable way of making sure what environment has been used to build a running application.

Thank you,
Peter A.

Hello Chuck,

Do you prefer to use subversion or tortoise GIT?

Thanks,
Bryan

Personally, I've used three different RCS systems. They have different advantages

Tlib, inexpensive but not free. Easy to setup and use. Probably the best of the three at archiving binaries, which is probably damning with faint praise. No server version but multi user using DOS/ Windows file locking. IME merging is mostly manual.


SVN, large, available free. Not easy to setup when I looked at doing so. Unix centric. I don't know if it is possible to use w/ o a server I've only used it on a presetup server. Really doesn't merge well.

Git, free, more complex to setup than Tlib but not dramatically so. Unix centric but less pronounced than SVN. Can be used with or without a server. It would in fact work reasonably well via sneakernet. Does not use locks but is built around branches and merges. Unlike the other two it does not have a built in version/ build number, it does have a concept of order between revisions in a branch but not between branches.

Personally I'd pick Git over SVN and use branches liberally. In Git branches are cheap, merging is easy. Branch per task allows easy management.

If you've not used an RCS before Tlib is a gentler introduction but I'm not entirely sure it's still available.

Robert

BTW, the choice of Tortoise is orthogonal to the choice of SVN or Git. There are Tortoise versions for both.

Robert

Hi Bryon,

Although I would like to provide a resounding recommendation for 1 or 2 of these types of systems, I don't have a lot of input on these matters at TI nor do I utilize them much at TI since I am not involved in a lot of SW development in my current role. In my not too distant past, I was, in fact, employed as a lead software engineer and have used many systems from proprietary to the overpriced name brand systems. In the end, I think that the best option is to evaluate your organizational needs, types of files you need to control, how many users are going to use it concurrently, etc and evaluate which will do the job for you.

By the way, TI has used GIT on a corporate level for some time but is currently evaluating other tools as a result of some changes to either the GIT organization or to an intermediate provider that we use (I am not familiar with all the details of this). The specific department that I work in also uses ClearCase to hold a variety of documents, source, executables, etc. (Note: this is in no way an endorsement or discouragement for either tool just data points and information that may be informative to you.)