Ticket #106 (closed defect: fixed)

Opened 10 years ago

Last modified 10 years ago

xuvtools: catastrophic error: could not open source file "mathfunc-win-x64.h"

Reported by: ne704 [niko@… Owned by: ne704
Priority: major Milestone:
Component: xuvtools Version: 1.6.0
Keywords: xuvtools, buildsystem, error, win Cc: mario@…, niko@…

Description

many errors like this:

2>f:\Devel\src\thirdparty\blitz-cvs-64bit-2009.09.25\blitz/vecuops.cc(10): catastrophic error: could not open source file "vecuops-win-x64.cc
2>  #  include "vecuops-win-x64.cc"

Change History

Changed 10 years ago by emmenlau

  • cc aaron@… added

I'm not in front of my computer right now, so this is a preliminary guess, but I think this can not relate to the new naming scheme.

The new naming scheme affects solely the XXX part of the output directories LMBSOFTDEST/{debug,release}_XXX/

The files in mention are created inside the source three, somewhere below LMBSOFTSRC/thirdparty/blitz-<VERSION>/

They should be generated by a corresponding genXXX executable, that is compiled and run by the compiler. Is it certain that the generate target was run? I use xuvbuild --genfirst for that.

Since the error appears to be new, it might still have something to do with my latest commits :-(

Changed 10 years ago by ne704 [niko@…

  • status changed from new to closed
  • resolution set to worksforme

I don't know what happened really, since I triple-checked to have a clean source-tree before compiling, but this seems to be a pointless bug-report. In other words: can't reproduce it anymore and hence will close it.

Sorry.

Changed 10 years ago by ne704 [niko@…

  • status changed from closed to reopened
  • cc aaron@… removed
  • summary changed from xuvtools: (most likely) the new naming-scheme breaks compilation on windows to xuvtools: catastrophic error: could not open source file "mathfunc-win-x64.h"
  • priority changed from trivial to major
  • keywords error, win added; error removed
  • resolution worksforme deleted

Have to reopen this bug, since I struggled with this issue again today.

It happened to me on a clean build from scratch using the buildscript, regardless if used with or without the "--genfirst" parameter, every time VS complains about missing headers:

5>f:\Devel\src\thirdparty\blitz-cvs-64bit-2009.09.25\blitz/mathfunc.h(10): catastrophic error: could not open source file "mathfunc-win-x64.h"
5>  #  include "mathfunc-win-x64.h"

Looks like something in generating them fails or just won't get executed at all. Really weird is the fact that opening the solution in VS instead of compiling from the commandline does not suffer from this problem: it just works then - and obviously (re)compiling from the commandline afterwards without cleaning the sourcetree works as well...

Changed 10 years ago by ne704 [niko@…

this is probably related to #92 (handle visual studio dependencies more intelligent)

Changed 10 years ago by emmenlau

A possible suggestion for a solution would be, to commit the generated files to SVN as well. I would still leave the re-generation in place, so the generated files would be overwritten on first compile. SVN will probably not show them as modified since they are generated equally.

We could also add a new CONFIG flag named "generate" that will enable generating the required source files, and have that disabled by default.

I don't know if that is really a good solution. The advantage would be, that everything would always be able to compile, and we have a lot less projects, and less dependency problems. The disadvantage is, that we need to commit all generated sources on every library update (not a lot of trouble, I admit).

Changed 10 years ago by emmenlau

  • status changed from reopened to closed
  • version set to 1.6.0
  • resolution set to fixed

Commited all auto-generated files to SVN quite a while ago, closing bug as outdated.

Note: See TracTickets for help on using tickets.