Oh, btw, I totally forgot: There's a third file that is created by the
OpenEXR build process on the fly,
"libraries/openexr/IlmImf/b44ExpLogTable.h", so make sure to take care
of that one as well.

Post a reply to this message

Am 24.09.2015 um 18:29 schrieb Benjamin Chambers:

> Now this is interesting. I've been over the XML for the project files,
> and they APPEAR to be set up correctly to generate the header files.
> 
> However, the custom build step never runs.
> 
> I'll keep poking around in it and see what I can do.

Just a hunch:

- Could it be due to the fact that (at least in the vs2010 projects) the
information for the respective custom build step is split across two
separate <CustomBuildStep> tags?

- Could it be that the custom build step does run after all, but doesn't
work properly because it contains an output redirection and the VS2015
build system somehow fails to handle this properly?

Post a reply to this message

On 9/24/2015 1:22 PM, clipka wrote:
> Just a hunch:
>
> - Could it be due to the fact that (at least in the vs2010 projects) the
> information for the respective custom build step is split across two
> separate <CustomBuildStep> tags?

Manually combining the tags in the project file had no effect.

> - Could it be that the custom build step does run after all, but doesn't
> work properly because it contains an output redirection and the VS2015
> build system somehow fails to handle this properly?

Removing the redirect still doesn't run the custom build step.

I've posted in the MSDN forums, asking if anyone knows why it wouldn't 
run, but haven't received an answer yet. In the meantime, I'll manually 
generate the header files, but this is something that needs to be sorted 
out eventually...

Post a reply to this message

Am 24.09.2015 um 18:29 schrieb Benjamin Chambers:

> Now this is interesting. I've been over the XML for the project files,
> and they APPEAR to be set up correctly to generate the header files.
> 
> However, the custom build step never runs.

As far as this is concerned, while testing with VS2010 I just noticed
that the description ("Creating toFloat.h..." or whatever) isn't
actually printed to the build output even if the custom build step
obviously runs (as demonstrated by toFloat.h reappearing after having
been deleted).

A hint that the custom build step was run seems to be a log file
generated in "build\toFloat\x64\Release" (in case of building for x64),
named "toFloat.write.1.tlog".

If you can't get the Custom Build Step mechanism to do the job, you
might want to try the Post-Build Event mechanism instead, though IIRC
there was /something/ undesirable about it.

Post a reply to this message

On 9/24/2015 1:44 PM, clipka wrote:
> As far as this is concerned, while testing with VS2010 I just noticed
> that the description ("Creating toFloat.h..." or whatever) isn't
> actually printed to the build output even if the custom build step
> obviously runs (as demonstrated by toFloat.h reappearing after having
> been deleted).
>
> A hint that the custom build step was run seems to be a log file
> generated in "build\toFloat\x64\Release" (in case of building for x64),
> named "toFloat.write.1.tlog".
>
> If you can't get the Custom Build Step mechanism to do the job, you
> might want to try the Post-Build Event mechanism instead, though IIRC
> there was /something/ undesirable about it.

I've tried both, actually, and neither one indicates in the log file 
that the step was run, nor do they generate the header file.

Post a reply to this message

Am 24.09.2015 um 23:55 schrieb Benjamin Chambers:
> On 9/24/2015 1:44 PM, clipka wrote:
>> As far as this is concerned, while testing with VS2010 I just noticed
>> that the description ("Creating toFloat.h..." or whatever) isn't
>> actually printed to the build output even if the custom build step
>> obviously runs (as demonstrated by toFloat.h reappearing after having
>> been deleted).
>>
>> A hint that the custom build step was run seems to be a log file
>> generated in "build\toFloat\x64\Release" (in case of building for x64),
>> named "toFloat.write.1.tlog".
>>
>> If you can't get the Custom Build Step mechanism to do the job, you
>> might want to try the Post-Build Event mechanism instead, though IIRC
>> there was /something/ undesirable about it.
> 
> I've tried both, actually, and neither one indicates in the log file
> that the step was run, nor do they generate the header file.

That's certainly strange. It does build the .exe that's supposed to
generate them, right?

Post a reply to this message

On 9/24/2015 4:17 PM, clipka wrote:
> Am 24.09.2015 um 23:55 schrieb Benjamin Chambers:
>> On 9/24/2015 1:44 PM, clipka wrote:
>>> As far as this is concerned, while testing with VS2010 I just noticed
>>> that the description ("Creating toFloat.h..." or whatever) isn't
>>> actually printed to the build output even if the custom build step
>>> obviously runs (as demonstrated by toFloat.h reappearing after having
>>> been deleted).
>>>
>>> A hint that the custom build step was run seems to be a log file
>>> generated in "build\toFloat\x64\Release" (in case of building for x64),
>>> named "toFloat.write.1.tlog".
>>>
>>> If you can't get the Custom Build Step mechanism to do the job, you
>>> might want to try the Post-Build Event mechanism instead, though IIRC
>>> there was /something/ undesirable about it.
>>
>> I've tried both, actually, and neither one indicates in the log file
>> that the step was run, nor do they generate the header file.
>
> That's certainly strange. It does build the .exe that's supposed to
> generate them, right?
>

Yes, and I ran it from the command line to generate the necessary headers.

There may be something odd with my specific installation causing this issue.

Post a reply to this message

I finally got the custom build step to generate the header as needed. 
I'm not sure which change made it, but what I did in the end to was to 
create a new project file, set it to run after link (instead of 
manifest), and set an Additional Dependency of $(TargetPath).

We'll see as I work with the other header-generating projects which 
change (or combination of them) was necessary.

Post a reply to this message

Benjamin Chambers <ben### [at] outlookcom> wrote:
> I finally got the custom build step to generate the header as needed.
> I'm not sure which change made it, but what I did in the end to was to
> create a new project file, set it to run after link (instead of
> manifest), and set an Additional Dependency of $(TargetPath).
>
> We'll see as I work with the other header-generating projects which
> change (or combination of them) was necessary.

Hi,
please Benjamin can you share your MSVC15 Project ?
I got same error plus some related to boost so if you have a working solution
for MSVC2015 on windows x64 I'll like to try it

regards

Post a reply to this message

Am 29.09.2016 um 10:28 schrieb Phane:
> Benjamin Chambers <ben### [at] outlookcom> wrote:
>> I finally got the custom build step to generate the header as needed.
>> I'm not sure which change made it, but what I did in the end to was to
>> create a new project file, set it to run after link (instead of
>> manifest), and set an Additional Dependency of $(TargetPath).
>>
>> We'll see as I work with the other header-generating projects which
>> change (or combination of them) was necessary.
> 
> Hi,
> please Benjamin can you share your MSVC15 Project ?
> I got same error plus some related to boost so if you have a working solution
> for MSVC2015 on windows x64 I'll like to try it

I would recommend trying a more recent version; The incompatibilities
with VS2015 have been ironed out in the master branch, and the VS2010
projects should build fine after auto-conversion.

Post a reply to this message