uint64_t, stdint.h on Visual Studio

[cp engr]

Why are the int64 types remmed out in cpputest\include\Platforms\VisualCpp\stdint.h?

Even more to the point, why does cpputest include stdint.h for Visual Studio at all? Why not just use the bundled stdint?

How can I make my project use Visual Studio's stdint instead? In a friendly, portable way.

Thanks,

cpengr

[cp engr]

> why does cpputest include stdint.h for Visual Studio at all? Why not just use the bundled stdint?

Apparently it wasn't included until VS 2010.

http://stackoverflow.com/questions/126279/c99-stdint-h-header-and-ms-visual-studio

My other questions remain.

Thanks,

cpengr

[A. Robert S.]

Hi,

 

stint.h is not needed I tested this with VC6 and VS2010, current HEAD. You may safely delete it. I suspect it wasn't needed in 3.6, either, but I didn't test that.

 

I assume it was needed when it was first added 4 years ago.

 

In your own projects, you may include whatever version of stint.h you see fit -- this is totally independent of CppUTest.

 

As for uint64_t, it was never in there to start with...

 

CppUTest strives very hard not to use stdint types at all, so as to maintain compatibility with old compilers, which is a bit of a disadvantage when programming 64bit Win applications because "long long" isn't a compatible type, either, and "long" is 32 bit data size, which is determined by Windows.

 

Regards,

Robert

[A. Robert S.]

As an afterthought -- it sounds like you mix CppUTest sources with your own source in your own projects. I wouldn't do that; I would build it once and only use includes and link the library in my own projects.

 

If you do that, you can include whatever stdint.h works for you (even if CppUTest internally depended on the redundant one, which it doesn't).

 

Regards,

Robert

On Thursday, April 16, 2015 at 1:55:00 AM UTC+2, cp engr wrote:

[cpengr]

I don't think I'm "mixing sources". Not on purpose, anyway.

I followed the walk through to create my Visual Studio solution, which results in the same thing as using the template provided. CppUTest is in its own project in the solution; my unit tests are in their own project in it. Your recommended method differs from this, right?

I do consider cpputest's stdint internal, so yes, I want my project to ignore it. Can you recommend any links on how to implement your suggestion in recent versions of VS?

Thanks,

cpengr

--
You received this message because you are subscribed to a topic in the Google Groups "cpputest" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cpputest/OS4OkxpK0QY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cpputest+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[A. Robert S.]

Hi there,

 

If CppUTest has its own project then, no, no sources should be mixed. In your project, you should have the following include paths set:

 

<root>\CppUTest\include

<root>\CppUTestExt\include

<your-own-include-paths>

 

If you do this, is CppUTest\include\Platforms\...\stint.h still attracted? As far as I can tell it shouldn't be, but I'm not sure how 3.6 behaves in that regard.

 

Also, depending on your version of CppUTest, you may simply delete it. I also deleted it from the current Head on Github.

[cp engr]

> Also, depending on your version of CppUTest, you may simply delete [stdint.h]. I also deleted it from the current Head on Github.

I'm tracking HEAD, so thanks for this update.

> In your own projects, you may include whatever version of stint.h you see fit -- this is totally independent of CppUTest.

I agree that it should be, but it wasn't... (Read on.)

> In your project, you should have the following include paths set:
>
> <root>\CppUTest\include
> <root>\CppUTestExt\include
> <your-own-include-paths>

I followed docs/WalkThrough_VS21010.docx pretty closely to set up my solution and project. Currently, my unit test project is set to "Inherit [additional include directories] from parent or project defaults", which results in inheriting $(CPPUTEST_INCLUDE_PATHS).

CPPUTEST_INCLUDE_PATHS of course is defined as a User Macro in the CppUTest_VS2010 property sheet:
$(CPPUTEST_HOME)\include;
$(CPPUTEST_HOME)\include\CppUTestExt\CppUTestGTest;
$(CPPUTEST_HOME)\include\CppUTestExt\CppUTestGMock;
$(CPPUTEST_HOME)\include\Platforms\VisualCpp     <-- item of interest


Interestingly, the include paths of the CppUTest project are only these:
.\include
.\include\Platforms\VisualCpp

It is also set to inherit, but to no additional effect. (Not even $(CPPUTEST_HOME).)


...Is all of the above expected and correct? It doesn't seem to align with what you wrote (quoted above).


Big picture: going forward, I think it would be best to separate CppUTest's public from private includes. I think this is already mostly the case(?), but it seems to me that one of the following is probably true.
1. include/Platforms/VisualCpp/ was intended as a private directory, and thus should not have been included in CPPUTEST_INCLUDE_PATHS.
2. include/Platforms/VisualCpp/ is intentionally public, but there should have been a private Platforms directory, and stdint.h should have been there.

Do you agree? Which one?

> CppUTest strives very hard not to use stdint types at all, so as to maintain compatibility with old compilers

Why not just have your own privately as needed by platform?


Thank you kindly for your work and help.

cpengr

[A. Robert S.]

This is not a complete answer. Just to let you know that in building CppUTest, I found an actual #include of <stdint.h> in a place where it absolutely shouldn't be and isn't needed, either. This is at the bottom of SimpleString.h. This line needs to go for CppUTest to compile cleanly.

Also, this is why I keep emphasizing that you must make a distinction between building CppUTest and building your own projects. Do not use the CppUTest project as a model / template for your own.

Including the platform specific folder of each respective platform is not only permissable, but essential building CppUTest.

In your own project, however, that path should NOT occur.

All you want from CppUTest in your own project is this:

Include paths: CppUTest/include

Library: CppUTest.lib

Library path: CppUTest/lib

#include "CppUTest/CommandlineTestRunner.h" (in your main)

#include "CppUTest/Testharness.h" (in your test .cpp)

#inlcude "CppUTestExt/MockSupport.h" (if using mocks)

Before my pending pull request, SimpleString.h will attract <stdint.h>, but it will use whatever you provide.

Kindly have a look at my comments below, also.

Regards,

Robert

On Tuesday, April 21, 2015 at 9:16:34 PM UTC+2, cp engr wrote:

> Also, depending on your version of CppUTest, you may simply delete [stdint.h]. I also deleted it from the current Head on Github.

I'm tracking HEAD, so thanks for this update.


> In your own projects, you may include whatever version of stint.h you see fit -- this is totally independent of CppUTest.

I agree that it should be, but it wasn't... (Read on.)


> In your project, you should have the following include paths set:
>
> <root>\CppUTest\include
> <root>\CppUTestExt\include
> <your-own-include-paths>

I followed docs/WalkThrough_VS21010.docx pretty closely to set up my solution and project. Currently, my unit test project is set to "Inherit [additional include directories] from parent or project defaults", which results in inheriting $(CPPUTEST_INCLUDE_PATHS).

I haven't looked at the walkthru much. But you should define your own include paths. The ones below are for the CppUTest project. NOT for your project. 

CPPUTEST_INCLUDE_PATHS of course is defined as a User Macro in the CppUTest_VS2010 property sheet:
$(CPPUTEST_HOME)\include;
$(CPPUTEST_HOME)\include\CppUTestExt\CppUTestGTest;
$(CPPUTEST_HOME)\include\CppUTestExt\CppUTestGMock;
$(CPPUTEST_HOME)\include\Platforms\VisualCpp     <-- item of interest


Interestingly, the include paths of the CppUTest project are only these:
.\include
.\include\Platforms\VisualCpp

Please don't use these either.

It is also set to inherit, but to no additional effect. (Not even $(CPPUTEST_HOME).)


...Is all of the above expected and correct? It doesn't seem to align with what you wrote (quoted above).


Big picture: going forward, I think it would be best to separate CppUTest's public from private includes. I think this is already mostly the case(?), but it seems to me that one of the following is probably true.
1. include/Platforms/VisualCpp/ was intended as a private directory, and thus should not have been included in CPPUTEST_INCLUDE_PATHS.
2. include/Platforms/VisualCpp/ is intentionally public, but there should have been a private Platforms directory, and stdint.h should have been there.

Do you agree? Which one?

No need to do this. Just set up a new project from scratch, along the lines of what I outlined at the top. 

> CppUTest strives very hard not to use stdint types at all, so as to maintain compatibility with old compilers

Why not just have your own privately as needed by platform?

It does do platform-specific stuff "privately" per platform. You are getting mixed up in this because you are using in YOUR project include paths that are meant to be PRIVATE to building CppUTest.

 

Thank you kindly for your work and help.

cpengr

N.B. in your case, I would advise not even to have the CppUTest project in your solution at all. Why have it there? You don't need to rebuild it all the time while working on your project.

[A. Robert S.]

I see the VC example projects do indeed contain strange include paths. Please remove the platform-specific one. It should not be needed.

[cp engr]

This is not a complete response...

> Also, this is why I keep emphasizing that you must make a distinction between building CppUTest and building your own projects. Do not use the CppUTest project as a model / template for your own.

I thought docs/WalkThrough_VS21010.docx was for CppUTest users, but I'm pretty sure you're telling me to deviate from it. Is it actually intended for CppUTest developers? In either case, I think it should be clarified. (To indicate who it's for; and if for users, to correct the include paths.) Or did I deviate somehow that caused $(CPPUTEST_INCLUDE_PATHS) to be a parent/project default?

What documentation are users expected to use to figure out how to set up their own unit test projects using CppUTest? Personally, I'm particularly interested in VS, obviously.

> N.B. in your case, I would advise not even to have the CppUTest project in your solution at all. Why have it there? You don't need to rebuild it all the time while working on your project.

Besides having followed the guide (tsk tsk on me, apparently), it is convenient to rebuild it in place when I update cpputest, especially since I'm tracking HEAD. It only builds when it changes, so that doesn't seem like an issue to me. Or am I missing something?


Thanks again for the detailed info and fixes.

cpengr

[Bas Vodde]

Not complete either :)

My first throught is that VS is different due to the lack of precompiled binaries and a package manager. So, for people using VS, they will probably use the project unless we create a Windows installed for CppUTest (should we?).

So… though on one hand the CppUTest VS project isn’t intended for users (as they should just include the lib and the includes), on the other hand a lack of a better way makes the VS project file intended for users :)

We’ll either need to make the project file more friendly or provide a better way of getting started.

Bas

You received this message because you are subscribed to the Google Groups "cpputest" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cpputest+u...@googlegroups.com.

[cpengr]

Hi Bas,

Thanks for chiming in.

> My first throught is that VS is different due to the lack of precompiled binaries and a package manager.

I'm not sure I know what you mean about the lack of precompiled binaries. Could you clarify?

> So, for people using VS, they will probably use the project unless we create a Windows installed for CppUTest (should we?).

Some thoughts and ideas...hopefully coherent and not too rambly.

Personally, at the moment, I'd much prefer to have a self-contained "thing" (library and/or project) that I can include in a solution, and does not require any setup on a new developer workstation. The developer just checks out the whole blob/solution from source control, and it works. Honestly, I don't even like that I have to set up the CPPUTEST_HOME environment variable, since it breaks that notion.

These preferences are of particular interest to me since in my current position, I'm just a one-off guy using CppUTest for (some of) my development tasks, on a project that I'm working on fairly independently. I don't have, nor am I in a position to push for, buy-in from a whole team, or making installing some particular test framework on many developer machines SOP (standard operating procedure).

With my current method (using the example project / walkthrough), warts aside, it makes it easy to track HEAD, and get the latest updates when I want them. Like now. ;) For me, quicker updates are preferable to static releases. So far, anyway. I hope any improvements you make wouldn't lose those advantages.

> We’ll either need to make the project file more friendly or provide a better way of getting started.

Yes please. ;)

Here is an idea:

• Have a push-button cpputest solution in the repo that can be used to generate static .libs.
• Have another solution (using the libs) in the repo which is the template for users.
  
• Periodically package the user solution with the libs and headers in a zip file as a release download.
• Probably with a release script...
  
• Also document how to generate these things, for users who want to stay more current, or branch/fork cpputest.
• Users doing this might want to use e.g. git submodules or svn externals to peg versions.
  

What do you think?

Thanks,

cpengr

[A. Robert S.]

Bas, I had a look at the example project, which I thought I was going to point cpengr to, and I discovered that these projects have strange include paths and the VC6 project was actually broken by mis-merge and then in quite a mess after fixing that. I'll take a look at it when I got time. The mis-merge was fixed quickly, but there are other problems. I will also look at the newer solution, when I have access to VC2010.

A person should not model the CppUTest solution, but should be able to take the example solution as a starting point, without winding up with weird dependencies.

Robert

[Bas Vodde]

Hi,

Yes, but it would be good if Windows users could just download a CppUTest lib? Perhaps we ought to try auto deploy the latest build binaries also for Windows (though the travis one is still broken :( )

Bas

[cpengr]

FWIW, I'm using VS2013. I had to make a couple of tweaks to get it working, so I'm on a custom branch. It's dirty/hackey, and I've been busy, so I haven't pushed or requested a pull.

That being to say...I'm not sure a lib generated by VS2010 would work for me...?

cpengr

[A. Robert S.]

The reason that isn't the case is that it would be six++ libs to distribute, two for each version of VS (Debug/Release).

@cp engr - I'll try to give a more detailed "how to" answer later.

For now:

1. Have a push-button cpputest solution -> build the CppUTest solution. Should put the lib into ./lib

2. Have another solution (using the libs) in the repo which is the template for users. -> Is meant to be there in ./examples, but definitely needs work

3. Periodically package... -> not as easy as it might appear, see above

4. Also document how to generate these things, -> obviously, this needs improvement

Regards,

Robert

[cpengr]

> The reason that isn't the case

The reason what's not the case?

> is that it would be six++ libs to distribute, two for each version of VS (Debug/Release).

Sounds related to why my VS2013 branch is dirty.

cpengr

--

[Bas Vodde]

Hola!

> My first throught is that VS is different due to the lack of precompiled binaries and a package manager.

I'm not sure I know what you mean about the lack of precompiled binaries. Could you clarify?

For Mac and Linux, most people use the apt-get or homebrew packages I guess. Windows doesn’t have an as standard package manager AFAIK.

Here is an idea:

• Have a push-button cpputest solution in the repo that can be used to generate static .libs.
• Have another solution (using the libs) in the repo which is the template for users.
  
• Periodically package the user solution with the libs and headers in a zip file as a release download.
• Probably with a release script...
  
• Also document how to generate these things, for users who want to stay more current, or branch/fork cpputest.
• Users doing this might want to use e.g. git submodules or svn externals to peg versions.
  

What do you think?

It sounds great to me… but … I’ve not worked on Windows for a long time :)

So, it is easy for me to say as I’m probably not the one figuring it out. I think Robert and Andy are probably the most active VS users at the moment, so they’ll probably need to do it.

Of course, you’re welcome to chime in. The Windows support could definitively need some additional help.

Bas

[cpengr]

> For Mac and Linux, most people use the apt-get or homebrew packages I guess. Windows doesn’t have an as standard package manager AFAIK.

I understood about the package manager. It's the "precompiled binaries" part that I'm unclear on.

> Of course, you’re welcome to chime in. The Windows support could definitively need some additional help.

Maybe. Time and expertise depending. We'll see, no promises, etc.

cpengr

[Bas Vodde]

Hola

> For Mac and Linux, most people use the apt-get or homebrew packages I guess. Windows doesn’t have an as standard package manager AFAIK.

I understood about the package manager. It’s the "precompiled binaries" part that I'm unclear on.

Oh, basically you and Robert continued that. I mean delivering lib files so you don’t need to open the CppUTest project and compile it first.

> Of course, you’re welcome to chime in. The Windows support could definitively need some additional help.

Maybe. Time and expertise depending. We’ll see, no promises, etc.

I understand. The wonderful life of an open source package :)

Bas

[A. Robert S.]

@cpengr - from a pragmatic point of view, do you have enough information to get going with your own solution / project, or would you need some more step-by-step information at this point?

 

Robert

[cpengr]

Sorry for the delay; got sidetracked. I do intend to get back to this...

[cp engr]

> do you have enough information to get going with your own solution / project

Yes, I got it working. Now
 - I use cpputest/CppUTest_VS201x.sln to build the library, and then
 - I pull cpputest/lib/CppUTestd.lib and cpputest/includes/ over into MyProjectUnitTests.sln.

Much nicer, much cleaner, and (I think) more maintainable. Thanks.

...If I can find time, I'm thinking about revising docs/WalkThrough_VS21010.docx to reflect this. Since things are kind of munged together there now, I envision separating into two main sections:

1. How to create CppUTest_VS201x.sln, to build cpputest. (This is most of what's already there, but I'd remove the part where you add your own projects in the same solution.)
2. How to create a separate solution to test your stuff, using CppUTest as a static library.

Sound good? Would I be duplicating anyone's work, or stepping on toes if I can find time to do this?

Thanks,

cpengr

[A. Robert S.]

Glad to hear! and yes, it would be nice if the WalkThrough was more helpful. I like your idea of the two different section.

Best,

Robert