how to re-compile a project with the same results of old compilation

We finally managed to find the problem.
it was a different option (Opt).
Thanks all

We finally managed to find the problem.
it was a different option (Opt).
Thanks all

there is one case where the "exact same" does not produce identical results.
I redid a piece of inherited code to make it adhere to the company coding standards and tried to match and it did not.
the "exact same" code does not produce the "exact same" .hex if you change variable names.

Erik

Unless any tool sorts the variables on name, the final output really should be the same - as long as "final output" is defined as a file format that doesn't contain debug information.

the "exact same" code does not produce the "exact same" .hex if you change variable names.

Depends on how you read "exact same".

To me (and certainly in our dev team), it must be 'the same as when originally created'; i.e., same source files, same configuration files, same compiler environment. An archive of the project is created at time of release.

The worst offender I know for such un-reproducability is Delphi. Build the project, take a copy of the file, rebuild, compare, see lots of differences.

With Keil C51, I've never seen such a problem.

This is why I prefer to ensure that a build batch file can be generated from the IDE settings. Then when you release a 'final' version, you can rebuild it with the archived source, along with the compiler, assembly, and linker executables.

Being able to reproduce the code, exactly, should be a priority when building executable code: especially if a ROM is going to be burned.

Although the IDE does save these configuration settings, a version change to the IDE can alter the output. Just like a revision to the command line executables can also cause an altered output.

But at least when you archive the build batch files and the command-line .EXE files, you won't need a full install of the IDE in order to re-create the exact output.

In order to do this, you must build the application [in a separate directory or even on a separate computer] with the items you officially archived, and use that output to do your formal qualification testing prior to release. It may sound like a hassle, but you will need to weigh the costs of an error in the field with this relatively minor effort.

As Mr. Westermark points out, things like __DATE__ and __TIME__ need special attention and consideration when using them.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

I normally create a revision string using the source code repository tools instead of using __DATE__ and __TIME in the file.

When the application boots, it will not present the time of compilation, but the time when a "version.h" file was committed. That makes sure that the version numbering and the time stamp belong together.

Best is when all production code can always be automatically checked out and built on a dedicated build machine. Howver, that is seldom possible for commercial tools since they normally require one license/machine, and does not allow multiple users to access the same installation.

But an even worse problem that is starting to crop up is that more and more companies rewrites their software licenses, requiring that after an update, the previous version of the application must be uninstalled and never, ever used again after maybe 7-30 days of overlap while validating that the new version is working.

I think the software industry is trying to dig its own grave by constantly creating more and more ridiculous licenses. Some licenses may even require several hours to read - if anyone actually bothers... My faviourite is the USB thumb drive - marketed for transfer of files between different computers, but with a license requiring that it is only used on one (1) computer.

I just hope that Keil and the other tool vendors realizes that when the license texts gets too strange, we will not just ignore the strangest parts of the licenses - we will ignore every single line of them. Or the product.

Many software companies seems to miss that the harder licenses they have, the more inclined their customers are to switch to alternative products, even if the alternative product may not be as good. A practically working solution always wins over a "perfect" tool that can't be used.

I just hope that ... tool vendors realizes that when the license texts gets too strange, we will not just ignore the strangest parts of the licenses - we will ignore every single line of them. Or the product.

I appreciate the vendors need to protect their software from piracy, but sometimes they seem to protect the legal, lawful owner of their software from 'pirating' what they already legally, lawfully own.

does anybody remember the old beautiful "book licence" (treat it as a book, only one can use at a time)

Well, once more thieves (no other word fits) makes it more difficult for normal honest people (no thieves, no need to lock the door) and we, probably have only two choices
a) shoot the thieves.
b) live with crummy protection schemes.

Erik

BTW I just realized I could have writtent just about the same thet I wrote about the thieves about the idiots that think it is fun to make vira, worms etc and force us to have out computers spend half the time to protect us and only half the time doing useful work.

shoot the thieves

?!

in Texas, they allow teachers to carry guns. I wonder if you support the same privilege for software engineers as well?

"does anybody remember the old beautiful "book licence" (treat it as a book, only one can use at a time)"

I very much miss the early Borland licenses - that was when they had good products and loyal customers. It was before they let ties take control of the company. After the ties came in, they were no longer allowed to admit known bugs and document possible work-arounds.

It didn't take too long to kill the company. What remains now is a broken shard, since they aliented themself from their end users - we developers.

I don't know how many companies they have bought to get access to new technology, and then failed badly since we customers don't trust them to stay focused and to value us.

shoot the thieves

?!
the only alternative to b) I know of

if you have another idea than a) and b) let's hear what it is. a) is never going to be implemented and just dropping b) would give the thieves a field day

Erik

the brain dead IT department that is so worried to keep my laptop running, keeps on making sure that my virus scanner
1. consumes 50% of the CPU most of the time
2. hogs the hard drive at the most inconvenient moments, and I cannot even shutdown the service anymore (they found out, damn it).

FYI Erik, THESE are villains I am prepared to shoot! or: where is my NRA membership card! :-)

by the way, some vendors lock their tools to a particular hardware configuration. but if many computers are identical (company buys masses when needed, and they are all the same - tool vendor probably don't check MAC address and other really unique stuff...), some can get smart (not me)...

"by the way, some vendors lock their tools to a particular hardware configuration."

Look no further than Keil.

The MAC address are at the top of the hw-locking list, since it makes sure that a company can't have two concurrently running machines with the same software unless they are in different network segments.

Not too many can afford to buy an extra license to put on a spare machine and dedicate a single user to be the one and only build master - besides the license the same person has on his/her own machine for actual development.

I was originally the only Keil user at our company, but we bougt a second license to make sure me and my machine would not be a single-point-of-failure.

Luckily, we can do 80% of our development with other tools, where redundancy isn't so expensive.

one licence per user was purchased (in one case 8, in another 3)

Eriki

We are starting to get way off-topic now :)

One license / user is quite normal. But one license / machine can feel a bit restrictive.

I have used a number of MS Visual Studio versions. I have normally installed every new version on a new computer.

If I need to maintain an old version originally developed -97, I can use the original environment as-is with Visual Studio 97 and all service packs installed. No need to spend time worrying about possible incompatibilities if the code is moved to a several releases newer edition. Most probably, the project history will even show the relevant project.

I didn't stop with Visual C++ until M$ got political and decided that the profiler should not be available in the largest "single-user" compiler package - now called Visual Studio Professional - but should instead only be available in their "team-edition" kits, where they splitted the product into different roles for different functions in a larger company - one release for testing, another for design, ... Somehow, they decided that if there is only a single user, there would be no need for any profiler - or that it was ok to charge almost three times as much ($6k instead of $2.3k) if a one-man operation needs the profiler. Or if a single user really needs to do both database design, development and testing, then all it takes is $18k..

There are limits how much a user may be pushed before he jumps ship, and a number of companies are quite busy focusing on short-term gains and not listening to grumblings from their users.

Pirates never have to bother about software licenses or which kit contains what feature. It's the honest customers who have to sit down and figure out the advantages of expensive commercial kits compared slightly worse commercial kits at a way lower price, or taking the jump all the way to open software. But people who have takend that final jump - and taken the costs to get started - seldom comes back. No more regular ticks for yearly subscriptions or support. So tool vendors really have to think twice about possible short-term gains from too hard licenses or stiff premium charges for the last few tool features.

One license / user is quite normal. But one license / machine can feel a bit restrictive.
well, how many users have more than one "machine"?

It's the honest customers who have to sit down and figure out the advantages of expensive commercial kits compared slightly worse commercial kits at a way lower price, or taking the jump all the way to open software. But people who have takend that final jump - and taken the costs to get started - seldom comes back. No more regular ticks for yearly subscriptions or support. So tool vendors really have to think twice about possible short-term gains from too hard licenses or stiff premium charges for the last few tool features.
Well, you, probably, have two groups of customers. Those that gladly accept "too hard licenses or stiff premium charges" for whatever benefit that gains them, and those that do not.
The only reason to pay the "stiff premium charges" is a productivity gain and if it comes with "too hard licenses" the productivity gain is gone.
Thus the vendors, if they want to succeed, need drop one of them.

Erik

well, how many users have more than one "machine"?

Would have thought it was quite common. We certainly have a number of people (me included) who take work away at the end of the day and continue with it at home - Occasionally with full days working at home.