In general it's fine, but includes are to be sorted by name.

Also, just for the record, it's a fix for msvc, right?

It's a bug discovered during an MSVC build, however it's arguably better style to include headers like this explicitly rather than relying on them to get pulled in by other headers. As an aside, the <cctype> header needs to be included for std::isspace, though I didn't do so in this patch because I thought you might want the two submitted separately.

Do you want me to edit this patch (if that's even possible), submit a new one, or just let you guys apply this admittedly trivial fix yourselves?

This patch was pushed to master branch now (commit hash rBac21db957a6c2f2723752c6a30734f06b0a667e3).

This it might be closed now.

Hi there!
Hope you guys are having a great Februaray. Just thought I'd let you know that I have just done a SVN update on trunk which should have pulled your patch but this is what I got after the update in the includes for msgfmt.cc

#include <algorithm>
#include <fstream>
#include <iostream>
#include <map>
#include <stdlib.h>
#include <string>
#include <vector>

it appears as though the other includes aren't there. I am grateful for your discussio above since I was getting an error that isspace is not in std due to the abscene of <cctype> in the includes which was corrected by adding

#include <cctype>

to the includes already in msgfmt.cc

If possible, can this issue be looked at again?

Cheers

J

@Jeducious (jameshcrowther), just to double-check i got you right: we're to add

#include <cctype>

to the msgfmt.cc ?

@Sergey Sharybin (sergey)

Hi Sergey!
Wow that was fast.... cool..... :), ok to clarify, yes, that is the correct addition. I built today the latest trunk revision in both release and debug using the plain vanilla Cmake options (i think, can post them if you like since they are stored in the cache, just ask and I can put them here for you).

I got errors at first complaining that isspace is not in std referring to msgfmt.cc They were all resolved once I inserted that line you quoted above.

#include <cctype>

What is more the lines you mentioned in your discussion above, such as <functional> were not in the mdgfmt.cc file that I updated from the svn repository today. This could mean your patch somehow did not make it into the trunk yet. Since I have no idea what goes on in that area, I have no clue what could have happened, I just know that in msgfmt.cc in the latest revision the <functional> include is missing and so is <cctype>.

Please don't hesitate to ask for more details if it helps!!

J

Well, we're no longer using SVNfor the sources and switched to Git. And <functional> should be in msgfmt.cc in latest sources from Git.

See https://developer.blender.org/diffusion/B/ for some details, clone instructions are there. Also, do you mind checkign compilation with the latest Git sources and see whether cctypes are really needed?

@Sergey Sharybin (sergey)

Sorry about that, I haven't checked in for a while with the blenderdev site. I am mainly developing in python and only build blender.exe to stay up to date with the development of the application. I'll try getting into git tomorrow. I have never used it. Got a bit too comfortable using svn. Probably wouldn't be a bad thing to learn a new skill. :)

@Sergey Sharybin (sergey)

sorry should have also added, for sure I don't mind at all. I'd like to see how the new setup works since I am keen to stay in the loop. Even though I am only using python, its really useful to have a bleeding edge build to see whats ahead.

Cheers

J

@Sergey Sharybin (sergey)

Hi again! Sorry for taking so long man. I have been distracted lately, wont bore you with the details. I have now got GIT on my build machine. The link you gave me above details how to clone the sources. HOwever to build I also need the libs, so, do we use git to clone the libs in a similar fashion and if so, what is the URL to use with git for doing this? Or do we still use the svn repo for this?

Libraries are still hosted in svn, nothing changed for them.

hi again Sergey,
So I tried to compile using source cloned from the GIT repository and libs as normal updated from the svn repository. First I used CMake to configure and generate the build tree. I have attached my cache so you can see what errors I got there. It seems that CMake could not find boost automatically so I had to set each lib path manually. That seemed to fix that issue but it is time consuming to set each boost lib separately.
I then used Visual Studio (see associated text file for version I am using) to open the blender.sln file and simply hit F7 or build solution. The attached screenshot shows the errors I got.

The first error in the list tells me that the openjpg.c file can't be found. This occured whilst building the bf_imbuf project. This seems rather odd since the files exists in;

(note I am using truncated file paths to conceal my username)

\blender\extern\libopenjpeg

So I simply set the additional include directories in MSVC to include this location and bf_imbuf built perfectly fine.

Next there are a whole series of errors, again, referring to a boost file that can't be found. This error is not new to me, it happened when the source was hosted under svn. But I could fix it easily and so didn't bother reporting it to anyone. The file seems to be missing from the bf_collada project.

The file which is missing is called "unordered_map" which is located in;

\lib\windows\boost\include\boost\tr1\tr1

Again, adding this to the additional include directories solves the issue.

I tried a rebuild of bf_collada and then another error occurs;

Error	15	fatal error C1083: Cannot open include file: 'boost/tr1/detail/config_all.hpp': No such file or directory	**********Obsfucated first part of the path**********\lib\windows\boost\include\boost\tr1\tr1\string	16	bf_collada

So I add the following path, again to the additional include directories;

\lib\windows\boost\include

Now bf_collada builds perfectly fine.
Next I build the blender projec to produce the executable. I get a series of link errors related to bf_imbuf complaining about missing symbols;

Error	1	error LNK2019: unresolved external symbol __imp__opj_image_destroy@4 referenced in function _imb_jp2_decode	bf_imbuf.lib	blender
Error	2	error LNK2019: unresolved external symbol __imp__opj_cio_close@4 referenced in function _imb_jp2_decode	bf_imbuf.lib	blender
Error	3	error LNK2019: unresolved external symbol __imp__opj_destroy_decompress@4 referenced in function _imb_jp2_decode	bf_imbuf.lib	blender
Error	4	error LNK2019: unresolved external symbol __imp__opj_decode@8 referenced in function _imb_jp2_decode	bf_imbuf.lib	blender
Error	5	error LNK2019: unresolved external symbol __imp__opj_cio_open@12 referenced in function _imb_jp2_decode	bf_imbuf.lib	blender
Error	6	error LNK2019: unresolved external symbol __imp__opj_setup_decoder@8 referenced in function _imb_jp2_decode	bf_imbuf.lib	blender
Error	7	error LNK2019: unresolved external symbol __imp__opj_set_event_mgr@12 referenced in function _imb_jp2_decode	bf_imbuf.lib	blender
Error	8	error LNK2019: unresolved external symbol __imp__opj_create_decompress@4 referenced in function _imb_jp2_decode	bf_imbuf.lib	blender
Error	9	error LNK2019: unresolved external symbol __imp__opj_set_default_decoder_parameters@4 referenced in function _imb_jp2_decode	bf_imbuf.lib	blender
Error	10	error LNK2019: unresolved external symbol __imp__opj_destroy_compress@4 referenced in function _imb_savejp2	bf_imbuf.lib	blender
Error	11	error LNK2019: unresolved external symbol __imp__cio_tell@4 referenced in function _imb_savejp2	bf_imbuf.lib	blender
Error	12	error LNK2019: unresolved external symbol __imp__opj_encode@16 referenced in function _imb_savejp2	bf_imbuf.lib	blender
Error	13	error LNK2019: unresolved external symbol __imp__opj_setup_encoder@12 referenced in function _imb_savejp2	bf_imbuf.lib	blender
Error	14	error LNK2019: unresolved external symbol __imp__opj_create_compress@4 referenced in function _imb_savejp2	bf_imbuf.lib	blender
Error	15	error LNK2019: unresolved external symbol __imp__opj_set_default_encoder_parameters@4 referenced in function _imb_savejp2	bf_imbuf.lib	blender
Error	16	error LNK2019: unresolved external symbol __imp__opj_image_create@12 referenced in function _ibuftoimage	bf_imbuf.lib	blender

I have tried to locate the .lib file that might have these symbols there, but so far I am not making good progress. I have looked in the blender lib\windows\jpeg\lib folder and noticed there was a .lib file here called libjpeg. However it does not contain the symbols that are refereed to above. So I am not sure where else to look. Any assistance here would be appreciated. For now I will turn off the CMake option WITH_IMAGE_OPENJPEG and see if I can compile without it. Though I am not sure what will happen without it. I worry that I may lose the ability to use the jpeg format. Though I am developing with this build and jpeg is not necessary just yet.

I'll let you know how the build goes without open jpeg, but I would like to know how to get it to link if you could help or ask someone that knows how?

Thanks again Sergey

James

Hi again Sergey

Turning off WITH_IMAGE_OPENJPEG seems to have worked. I now no longer get the warnings I posted about above. I was able to build the INSTALL project and run blender v 2.70 from the resulting executable. I rendered the default scene and surprisingly I was able to save the render result to a .jpeg image. So it seems that the WITH_IMAGE_OPENJPEG is not needed. Any reason why that might be?

Also kind of curious as to why this option causes link errors.

James

@Sergey Sharybin (sergey)
Hi sergey,

Sorry for taking so long to get back to you again, I didn't use the @ convention above for some reason, I think that may have prevented you from seeing the posts I made above. As you can tell from these posts, I have had some issues using the GIT repository. It would be great if you could look at what I posted and see if there are any issues there for the broader blender dev community.
Needless to say, it didn't work for me out of the box.

Regards

James

@Jeducious (jameshcrowther),

I'm not really sure what's going on here, it works for me on windows.

And this kind of discussion better not to happen in patch review page, be welcome to ask for help in our bf-committers mailing list. Would be much more efficient i think.