Windows build broken?

Folks,

It appears the Windows build has regressed over the past week.

The build fails quite early (during the "Performing TableGenStep" phase).

Any help/pointers would be appreciated.

Thanks,

snaroff (a clang developer)

steve naroff <snaroff@apple.com> writes:

Folks,

It appears the Windows build has regressed over the past week.

The build fails quite early (during the "Performing TableGenStep"
phase).

Any help/pointers would be appreciated.

It breaks for me because the usage of INT64_C, which was introduced on
r57663 and 57668.

Some googling around indicates that, on Windows, one should

#define INT64_C(val) val##i64

It is present on TableGen/DAGISelEmitter.cpp and TableGen/Record.cpp.

Óscar Fuentes <ofv@wanadoo.es> writes:

It appears the Windows build has regressed over the past week.

The build fails quite early (during the "Performing TableGenStep"
phase).

Any help/pointers would be appreciated.

It breaks for me because the usage of INT64_C, which was introduced on
r57663 and 57668.

Some googling around indicates that, on Windows, one should

r/Windows/MSVC++

This patch brings the build fordward:

Index: utils/TableGen/Record.cpp

Oops, I had fixed the "DataTypes.h" copy instead of the versioned "DataTypes.h.in" and missed the commit, sorry about that.

-Argiris

Óscar Fuentes wrote:

Óscar Fuentes wrote:

steve naroff <snaroff@apple.com> writes:

Folks,

It appears the Windows build has regressed over the past week.

The build fails quite early (during the "Performing TableGenStep" phase).

Any help/pointers would be appreciated.
    
It breaks for me because the usage of INT64_C, which was introduced on
r57663 and 57668.

Some googling around indicates that, on Windows, one should

#define INT64_C(val) val##i64
  

On MSVC. MingW32 provides this macro in stdint.h.

Kenneth

I have updated "DataTypes.h.in", could you do a svn update and see if it works ?

-Argiris

Óscar Fuentes wrote:

Argiris Kirtzidis <akyrtzi@gmail.com> writes:

I have updated "DataTypes.h.in", could you do a svn update and see if it
works ?

Your change has been superseded by

http://llvm.org/viewvc/llvm-project?rev=58048&view=rev

Now tblgen.exe builds fine with my CMake build system. Guess it is the
same case for the VC++ project files.

Oh, does clang building work with CMake? If not, wanna cons it up? :slight_smile: Thanks.

Mike Stump <mrs@apple.com> writes:

Now tblgen.exe builds fine with my CMake build system. Guess it is
the same case for the VC++ project files.

Oh, does clang building work with CMake? If not, wanna cons it
up? :slight_smile: Thanks.

Giving a compelling reason why you'll like to build clang using CMake
instead of configure && make would help to speed up things :slight_smile:

Apart from me, I only know of one person that tried CMake, and it was by
accident.

Right now CMake works for me and does what I need. It achieved the
primary goal of being a replacement for the VC++ project files (it needs
to be described on the LLVM docs, but this will happen soon). I know
there are lots of things to be done for being a general replacement of
LLVM's build system, but if there is no feedback, this will progress
slowly.

Please note that I'm, mostly, a Windows guy with a very limited set of
requirements on LLVM (just the JIT) so I'm totally unaware of the
expectations most of you have.

I'm specially interested on why you dislike the current build system
(for not doing the same mistakes again), what you'll like to see
implemented (to improve on what we have) and what features are mandatory
for using the new system on a regular basis.

Well I tried it on linux, and it sounds like it worked. Well llvm was build
without error, but since I prefer to stick to released llvm, I didn't if the
results of the compilation was usuable :wink:

The last time I tried it on OS X, the cmake file did not correctly generate the config.h. (There is a lots of hardcoded value in config.h.cmake that should be replaced by cmakedefine equivalent).

How does updating the CMake produced VC++ project files work ?
I mean:

-I have CMake produce VC++ project files
-Compile the solution
-Do a svn update and pick up a couple of files
-Have CMake produce new project files
-Now, do I have to rebuild the entire solution again ?

-Argiris

Argiris Kirtzidis <akyrtzi@gmail.com> writes:

How does updating the CMake produced VC++ project files work ?
I mean:

-I have CMake produce VC++ project files
-Compile the solution
-Do a svn update and pick up a couple of files
-Have CMake produce new project files
-Now, do I have to rebuild the entire solution again ?

AFAIK, it should do the right thing automatically, regenerating the
project files on the fly and recompiling only what is outdated. You
don't even need to explicitly invoke cmake after a svn update.

This is my understanding from reading the CMake ml. I tend to use nmake.

I think the reasons we would like to have CMake for clang are the same as for LLVM, manually maintaining the project files is a big pain and not done by that many developers.

I don’t have any experience with CMake but I did try it out and it seemed to work well, unfortunately I only have VS 2003 so I got blocked on C++ issues building with that compiler. However, the project file generation stuff worked fine – thanks for your effort on it!

  • Daniel

"Daniel Dunbar" <daniel@zuster.org> writes:

I think the reasons we would like to have CMake for clang are the same as
for LLVM, manually maintaining the project files is a big pain and not done
by that many developers.

So far, the only sound reason for extending CMake to the point of being
a replacement for configure && make is to lessen maintenance work. This
is achievable, but it will take time. Having some priorities, for
achieving a point where the CMake build is mature enough to be an option
for most users, and therefore being thoroughly tested, will speed up
things. I'm not specially excited about replicating random features,
warts and all.

I don't have any experience with CMake but I did try it out and it seemed to
work well, unfortunately I only have VS 2003 so I got blocked on C++ issues
building with that compiler. However, the project file generation stuff
worked fine -- thanks for your effort on it!

You are welcomed. But the build should work (*) on Linux too:

cmake -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX=/some/path path/to/llvm/root
make
make install

(*) Bug reports welcomed.

Jean-Daniel Dupas <devlists@shadowlab.org> writes:

The last time I tried it on OS X, the cmake file did not correctly
generate the config.h. (There is a lots of hardcoded value in
config.h.cmake that should be replaced by cmakedefine equivalent).

This is an area that needs improvements to work on platforms where I
have no access. So far it seems it works on Linux/x86 and MinGW (VC++
uses a different configuration system, although I plan to remove it).

As there are ~200 variables in config.h and only ~70 tests are performed
right now by the CMake build, it will take some time to implement them
all. But if you know which tests are missing for your platform, I'll
incorporate them ASAP.

Óscar Fuentes wrote:

Argiris Kirtzidis <akyrtzi@gmail.com> writes:

How does updating the CMake produced VC++ project files work ?
I mean:

-I have CMake produce VC++ project files
-Compile the solution
-Do a svn update and pick up a couple of files
-Have CMake produce new project files
-Now, do I have to rebuild the entire solution again ?
    
AFAIK, it should do the right thing automatically, regenerating the
project files on the fly and recompiling only what is outdated. You
don't even need to explicitly invoke cmake after a svn update.

This is my understanding from reading the CMake ml. I tend to use nmake.

I gave it a try and unfortunately it doesn't seem practical to use CMake-produced VC++ projects. Every time you run CMake so that the VC++ projects include new files, the entire solution gets rebuilt.

-Argiris

Argiris Kirtzidis <akyrtzi@gmail.com> writes:

I gave it a try and unfortunately it doesn't seem practical to use
CMake-produced VC++ projects. Every time you run CMake so that the VC++
projects include new files, the entire solution gets rebuilt.

I recall some discussion about the behavior you describe on the cmake
ml, but can't find it right now.

IIRC, once generated the project files, you shouldn't need to re-run
cmake, ever. CMake inserts something in the project files for detecting
that a re-generation is needed and automatically stops the build and
invokes itself, then continue, perhaps with some intermediate prompt by
the IDE about changed files, etc.

If this doesn't work for you, please comment it on the cmake ml. Don't
forget to mention the version you are using, etc.

Argiris Kirtzidis <akyrtzi@gmail.com> writes:

I gave it a try and unfortunately it doesn't seem practical to use
CMake-produced VC++ projects. Every time you run CMake so that the VC++
projects include new files, the entire solution gets rebuilt.

Forgot to mention that right now all executables depend on all libraries
(for the MSVC++ case, for the others llvm-config is used to determine
the dependencies). So if you modify one library, all executables will
need relinking. This is not too hard to fix, but creates some
maintenance work. Using the MSVC++ build on this state would be a major
pain for a LLVM developer but, as my knowledge goes, there are not much
of them (if any) using MSVC++. The VC++ cmake build system, as
implemented today, is oriented towards LLVM users who do not update
frequently (those using the official releases, for instance).

Óscar Fuentes wrote:

Argiris Kirtzidis <akyrtzi@gmail.com> writes:

I gave it a try and unfortunately it doesn't seem practical to use CMake-produced VC++ projects. Every time you run CMake so that the VC++ projects include new files, the entire solution gets rebuilt.
    
I recall some discussion about the behavior you describe on the cmake
ml, but can't find it right now.

IIRC, once generated the project files, you shouldn't need to re-run
cmake, ever. CMake inserts something in the project files for detecting
that a re-generation is needed and automatically stops the build and
invokes itself, then continue, perhaps with some intermediate prompt by
the IDE about changed files, etc.
  
Thanks for the tip. For a simple test I added a file entry in tools/llc/CMakeLists.txt and, after doing "Build Solution", CMake recreated 7 project files, resulting in building 41.
Why wasn't just the llc project affected, do the dependencies need tweaking or something ?

-Argiris