Folks,
Is anyone still using the Visual Studio solution files in the win32 directory?
If they aren't being maintained, they should probably be removed (to avoid any confusion).
Thanks for any feedback,
snaroff
I am still using them for llc/llvm-as/opt/llvm-dis/tablegen and a few
others.
"Villmow, Micah" <Micah.Villmow@amd.com> writes:
I am still using them for llc/llvm-as/opt/llvm-dis/tablegen and a few
others.
The VS project files generated with CMake should build those.
Hi,
I just moved to the CMake solution. By the way, the generated libs haven't the same names. In my opinion, we have to choose one way and remove the other one. If it helps, you can put in the win32 directory the result of CMake, or add a script that generate this win32 directory with cmake.
Gab
Hi Steve,
The Visual Studio solution and project files are quite handy. CMake creates
absolute paths instead of relative paths, making it cumbersome to move
things around. Also, for newcomers (e.g. students) it's really great to be
able to download the package, open the solution and compile without any
complication.
They haven't been updated in a while, but it would be nice to have working
ones in the 2.5 release...
Cheers,
Nicolas
Mondada Gabriele <g.mondada@etel.ch> writes:
I just moved to the CMake solution. By the way, the generated libs
haven't the same names.
Which ones? The only difference is that we now generate .lib files where
.obj were generated on the past, and require a parameter to be passed to
the linker for including them on the final executable.
In my opinion, we have to choose one way and remove the other one. If
it helps, you can put in the win32 directory the result of CMake,
On the release tarball? It seems a good idea (as far as someone
volunteers to do the work) but someone mentioned on this thread that the
project files generated with CMake contains absolute paths.
or add a script that generate this win32 directory with cmake.
The amount of work saved by such script would be almost nil, and it can
cause problems on setups with more than one compiler installed.
"Nicolas Capens" <nicolas@capens.net> writes:
The Visual Studio solution and project files are quite handy. CMake creates
absolute paths instead of relative paths, making it cumbersome to move
things around. Also, for newcomers (e.g. students) it's really great to be
able to download the package, open the solution and compile without any
complication.They haven't been updated in a while, but it would be nice to have working
ones in the 2.5 release...
There is a contradiction among this two paragraphs: the first one says
"they are convenient" and the second one says "they are outdated".
The primary goal of the LLVM CMake build system was to alleviate
maintenance work, the second was to support all VS versions wich are C++
compliant enough to compile LLVM. Another nice side-effect is that now
VS users can build all LLVM targets. The VS project files under win32/
are good enough as far as someone maintains them, you have the correct
VS version and don't need the missing functionality.
Finally, a student that works with LLVM is not a computer newbie: he
knows how to follow web links, install a piece of software, and
copy/paste onto a console. This process requires less time than the LLVM
build itself.
Of course, this requires that the LLVM CMake instructions should become
integrated into the LLVM docs. I hope to do this before the 2.5 release.
Please, don’t remove, I’m using!!!
Regards,
Makslane
> I just moved to the CMake solution. By the way, the generated libs
> haven't the same names.Which ones? The only difference is that we now generate .lib files
where
.obj were generated on the past, and require a parameter to be passed
to
the linker for including them on the final executable.
I was linking with
VMCore.lib support.lib System.lib Analysis.lib CodeGen.lib Target.lib Transforms.lib
and I'm now linking with
LLVMVMCore.lib LLVMScalarOpts.lib LLVMSelectionDAG.lib LLVMSupport.lib LLVMSystem.lib LLVMAnalysis.lib LLVMCodeGen.lib LLVMTarget.lib LLVMTransformUtils.lib LLVMAsmPrinter.lib
> In my opinion, we have to choose one way and remove the other one. If
> it helps, you can put in the win32 directory the result of CMake,On the release tarball? It seems a good idea (as far as someone
volunteers to do the work) but someone mentioned on this thread that
the
project files generated with CMake contains absolute paths.
Right, I just look inside the .vcproj files generated by CMake and paths are absolute, even by using the command line version of cmake and by specifying relative paths.
Makslane Araújo Rodrigues
<makslane@hotmail.com> writes:
Please, don't remove, I'm using!!!
What's preventing you from using CMake?
Is there some problem we can solve?
Mondada Gabriele <g.mondada@etel.ch> writes:
> I just moved to the CMake solution. By the way, the generated libs
> haven't the same names.Which ones? The only difference is that we now generate .lib files
where .obj were generated on the past, and require a parameter to be
passed to the linker for including them on the final executable.I was linking with VMCore.lib support.lib System.lib Analysis.lib
CodeGen.lib Target.lib Transforms.lib
and I'm now linking with
LLVMVMCore.lib LLVMScalarOpts.lib LLVMSelectionDAG.lib LLVMSupport.lib
LLVMSystem.lib LLVMAnalysis.lib LLVMCodeGen.lib LLVMTarget.lib
LLVMTransformUtils.lib LLVMAsmPrinter.lib
I forgot that.
Please note that the LLVM CMake build generator works for VS, MinGW,
Linux, OS/X... The same library names are used across all platforms
(plus platform-dependent prefixes/suffixes). The best part of this is
that a single CMake specification for your compiler would work on all
platforms LLVM supports with almost no changes.
At some point, we'll need to deal with the testing issue in the CMake build system. Clang, for example, uses some GNU make magic to run its tests, which we'll need to replace with something more platform-neutral in CMake.
That shouldn't prevent anyone who is using the current VS project files from switching to CMake, though.
- Doug
Douglas Gregor <dgregor@apple.com> writes:
Please, don't remove, I'm using!!!
What's preventing you from using CMake?
Is there some problem we can solve?
At some point, we'll need to deal with the testing issue in the CMake
build system. Clang, for example, uses some GNU make magic to run its
tests, which we'll need to replace with something more platform-
neutral in CMake.
Testing was (is) the big roadblock for the LLVM CMake system. It is not
practical to duplicate the make-based system we have now, but I think a
good compromise can be achieved by invoking a script instead of
`make'. The build could use this script for doing full testing, so
"make all check"
would keep working, although for partial testing the script would be
mandatory. If this is not already working, is due to lack of time here.
OTOH, I haven't followed in detail all that discussion around a new
testing framework (plus the introduction of C++ unit tests). I need to
relearn was going on and see how that affects my plans.
That shouldn't prevent anyone who is using the current VS project
files from switching to CMake, though.
Right. Current VS project files does not support testing at all.
Hi Oscar,
For development, CMake is working great for me. I rarely get build errors related to the project file being out-of-date.
Is it true that CMake only generates absolute paths? Any idea on the difficulty of generating relative paths? I consider this a pretty big obstacle...
Thanks for all your hard work on this,
snaroff
Is it true that CMake only generates absolute paths? Any idea on the difficulty of generating relative paths? I consider this a pretty big obstacle...
It is probably impossible, by design:
From the CMake FAQ: CMake Wiki has moved
Why does CMake use full paths, or can I copy my build tree?
CMake uses full paths because:
- configured header files may have full paths in them, and moving those files without re-configuring would cause upredictable behavior.
- because cmake supports out of source builds, if custom commands used relative paths to the source tree, they would not work when they are run in the build tree because the current directory would be incorrect.
- on Unix systems rpaths might be built into executables so they can find shared libraries at run time. If the build tree is moved old executables may use the old shared libraries, and not the new ones.
Can the build tree be copied or moved?
The short answer is NO. The reason is because full paths are used in CMake, see above. The main problem is that cmake would need to detect when the binary tree has been moved and rerun. Often when people want to move a binary tree it is so that they can distribute it to other users who may not have cmake in which case this would not work even if cmake would detect the move.
The workaround is to create a new build tree without copying or moving the old one.
Hi Steve,
For development, CMake is working great for me. I rarely get build
errors related to the project file being out-of-date.Is it true that CMake only generates absolute paths? Any idea on the
difficulty of generating relative paths? I consider this a pretty big
obstacle...
I did not follow the full-thread, just reading this Email and I hope I'm getting it right:
We had the same problem (relative paths) and it turned out to be relatively (got the language joke here? ;)) easy, at least with cmake 2.6, in a local project.
set(CMAKE_USE_RELATIVE_PATHS ON)
It works well for vcproj-generation. In Linux I could not test it comprehensively yet (as to why it is possible to copy a repository and build it in its new place w/o re-cmaking.)
In addition we are setting
set(CMAKE_SUPPRESS_REGENERATION ON)
in order to not have a dependency on the CMakeLists when creating the vcproj-file.
HTH,
Patrick.
Patrick Boettcher <pb@linuxtv.org> writes:
For development, CMake is working great for me. I rarely get build
errors related to the project file being out-of-date.Is it true that CMake only generates absolute paths? Any idea on the
difficulty of generating relative paths? I consider this a pretty big
obstacle...I did not follow the full-thread, just reading this Email and I hope I'm
getting it right:We had the same problem (relative paths) and it turned out to be
relatively (got the language joke here? ;)) easy, at least with cmake 2.6,
in a local project.set(CMAKE_USE_RELATIVE_PATHS ON)
It works well for vcproj-generation. In Linux I could not test it
comprehensively yet (as to why it is possible to copy a repository and
build it in its new place w/o re-cmaking.)
Hmmm...
CMAKE_USE_RELATIVE_PATHS
Use relative paths (May not work!).
If this is set to TRUE, then the CMake will use relative paths between
the source and binary tree. This option does not work for more
complicated projects, and relative paths are used when possible. In
general, it is not possible to move CMake generated makefiles to a
different location regardless of the value of this variable.
In addition we are setting
set(CMAKE_SUPPRESS_REGENERATION ON)
in order to not have a dependency on the CMakeLists when creating the
vcproj-file.
This looks like asking for trouble. Why are you doing this?
Hello Steve.
steve naroff <snaroff@apple.com> writes:
For development, CMake is working great for me. I rarely get build
errors related to the project file being out-of-date.Is it true that CMake only generates absolute paths? Any idea on the
difficulty of generating relative paths? I consider this a pretty big
obstacle...
Well, the fact that you didn't *still* noticed this limitation makes me
think that this is rarely needed 
Can you describe on which scenario do you require to move around build
trees?
Hello Steve.
steve naroff <snaroff@apple.com> writes:
For development, CMake is working great for me. I rarely get build
errors related to the project file being out-of-date.Is it true that CMake only generates absolute paths? Any idea on the
difficulty of generating relative paths? I consider this a pretty big
obstacle...Well, the fact that you didn't *still* noticed this limitation makes me
think that this is rarely needed
I haven't noticed it because I've been on the "development" side (where the absolute paths aren't a problem).
Can you describe on which scenario do you require to move around build
trees?
Sure...
As various clang features mature, we enter a "deployment" phase. As part of deployment, it is necessary to provide Apple's Build & Integration team a self-contained source tree that builds properly. This is where the rub is. It isn't appropriate to ask B&I engineers to use "cmake".
That said, I want to generate the VS solution files on my local machine and then copy them to a B&I machine and have everything "just work". For example:
snaroffBook% ls /Volumes/Data/WindowsShared/objc_translate-9/
llvm vs2005-build
The VS solution files located in "vs2005-build" were built with the following command "cmake ../llvm". Since I am using a relative path on the command line, I assumed it would use relative paths (my bad assumption).
Another point...I have no need to ever "move" the cmake generated build files away from the source tree. The source tree and the build tree will always move in lock step (which simplifies the problem I am looking to solve).
Thanks for any help with this,
snaroff
Hi Steve,
The Visual Studio solution and project files are quite handy. CMake creates
absolute paths instead of relative paths, making it cumbersome to move
things around. Also, for newcomers (e.g. students) it's really great to be
able to download the package, open the solution and compile without any
complication.
Understood, however the (unfortunate) reality is the VS solution file is not being properly maintained. As a result, any newcomer/developer is faced with updating the VS solution file (or not building at all).
Over the past 6 months, I've had to personally fix many problems with the solution file. That said, I'm grateful that cmake works and the cmake.txt files are being updated/maintained. It does require an extra step, however the work is "constant time" (whereas fixing regressions without cmake could take an arbitrary amount of time).
Thanks for your response...
snaroff