Yes, it's reasonable. Moreover, I'd be content with a build system that
doesn't use MSVS IDE at all. If the build system could be
parameterized to use microsoft cl compiler (cygwin gcc is useless for
my purposes), e.g. something like in Boost project, I'd be more than
happy to never care about VS project files. Yet, I want to limit my
involvement with the llvm/clang project to completely orthogonal
modifications, i.e. I have no interest to modify the build system on my
own.
Since this is open source we depend on contributions from the community,
etc... You know how the song goes.
Seriously, I'll like to see a healthy MSVS build as much as you, but
someone must do the work.
Moreover, I'd be content with a build system that doesn't use MSVS IDE
at all.
Seconded.
If the build system could be
parameterized to use microsoft cl compiler (cygwin gcc is useless for
my purposes), e.g. something like in Boost project, I'd be more than
happy to never care about VS project files.
I use GNU Make for building my software and the build system supports
several compilers on various platforms, including gcc and cl. It is
tricky, though.
I don't know how much LLVM build system is tied to the GNU toolchain or
how much it depends on *nix features, but suppossing that adding support
for MSVC++ is impractical, perhaps it would be simpler to implement a
Makefile-based build system for MSVC++ than to keep up to date the
project files. This would support features like the one Anton mentions
on the other response to you, thus lessening the maintenance work. A
really nice thing is that, in principle, a makefile-based build system
would work the same for VS 2003, 2005 and 2008.
Note that I'm not volunteering to do the work... for now. If things
follow certain path here, I will incorporate LLVM to production on a
year or so, and this means solid MSVC++ support (for the JIT, at
least). Don't count too much on it, though
Frankly, the LLVM build machinery could use a good scrubbing. Also, maintenance of parallel project files really sucks, if we have to continue doing this, life for non-unix people will continue to be an unhappy one.
Others have suggested alternative build systems before like cmake. Apparently cmake can autogenerate VC++ and Xcode project files from the same thing that it builds from on unix systems. Has anyone used cmake in a real system before? Are there other worthwhile alternatives? To me, I think it would be interesting to switch over llvm and clang (probably start with clang since it is very small) and do other things later (e.g. llvm-test may never change off gmake, gmake is too useful there).
Others have suggested alternative build systems before like cmake.
Apparently cmake can autogenerate VC++ and Xcode project files from
the same thing that it builds from on unix systems.
cmake creating VC++ project files does not appeal much to me. First,
project files are not mandatory for using MS compiler. Second, I'm
afraid that things like intermediate script invocations may be
translated incorrectly to VC++ projects.
Actually, gmake works well with VC++. The only odd thing is that I use
other compiler (gcc or Intel's icl) for generating header file
dependencies, as VC++ does not output them on a format that gmake
understands (this could be solved with some awk processing).
Has anyone used cmake in a real system before? Are there other
worthwhile alternatives?
Sure. Lots of them. I studied some a few years ago and concluded that it
was not worth the trouble.
Specifically, some of those systems (can't remember which ones) makes
very easy to do essential things that for gmake are a bit complicated,
but then makes very difficult to achieve things that are just a bit
complicated too in gmake.
I don't know how much LLVM build system is tied to the GNU toolchain or
how much it depends on *nix features, but suppossing that adding support
for MSVC++ is impractical, perhaps it would be simpler to implement a
Makefile-based build system for MSVC++ than to keep up to date the
project files. This would support features like the one Anton mentions
on the other response to you, thus lessening the maintenance work. A
really nice thing is that, in principle, a makefile-based build system
would work the same for VS 2003, 2005 and 2008.
Frankly, the LLVM build machinery could use a good scrubbing. Also, maintenance of parallel project files really sucks, if we have to continue doing this, life for non-unix people will continue to be an unhappy one.
Others have suggested alternative build systems before like cmake. Apparently cmake can autogenerate VC++ and Xcode project files from the same thing that it builds from on unix systems. Has anyone used cmake in a real system before?
Systems that I've worked with in the past have been platform agnostic (gmake, nant, etc) and have used a flat text format source file/directory list to specify the source files to build.
This flat text file is then used by scripts (whether c# or python or something else) to generate solution/project files for MSVS or any other IDE you wish to use.
These scripts can either be run as a special build target (make solution) or as a hook on svn post-commit, or both. Given that LLVM assumes build everything in a folder as a policy, this system becomes very easy to maintain: Only the addition of a folder will require a new line in the flat text file.
Others have suggested alternative build systems before like cmake. Apparently cmake can autogenerate VC++ and Xcode project files from the same thing that it builds from on unix systems. Has anyone used cmake in a real system before? Are there other worthwhile alternatives?
I can recommend omake (http://omake.metaprl.org/index.html). My company uses it for a large project with many directories, several source languages, some tricky preprocessing, under Unix and Windows (MSVC and MinGW toolchains). We have been very happy with it.
omake would add an extra build-time dependency to LLVM (i.e. it does not generate "native" Makefiles and project files), but I think it's worth considering it.
Others have suggested alternative build systems before like cmake.
Apparently cmake can autogenerate VC++ and Xcode project files from
the same thing that it builds from on unix systems. Has anyone used
cmake in a real system before?
To me, I think it would be interesting to switch over
llvm and clang (probably start with clang since it is very small) and
do other things later (e.g. llvm-test may never change off gmake,
gmake is too useful there).
I never liked the autotools. CMake looks much friendlier at a first glance.
> Others have suggested alternative build systems before like cmake.
> Apparently cmake can autogenerate VC++ and Xcode project files from
> the same thing that it builds from on unix systems.
cmake creating VC++ project files does not appeal much to me. First,
project files are not mandatory for using MS compiler.
cmake can create nmake files as well. It's also possible to add a different
generator that use something else (even one that would output to gmake and
use msvc compiler and gcc for header dependencies ).
Second, I'm
afraid that things like intermediate script invocations may be
translated incorrectly to VC++ projects.
Calling external program works correctly, I am not sure why it woud be
different for script invocations.
> Has anyone used cmake in a real system before?
Kitware (the creators of cmake) products (VTK and ITK), KDE, scribus, inkscape
for the biggest project I know which use cmake. All of them use it for
building on windows, mac os x and unixes. But, at least, for KDE, I am not
sure if for mac os x, anyone has try to use it with Xcode.
Personnally, I use cmake for building a project (OpenGTL) that link to llvm.
Others have suggested alternative build systems before like cmake.
Apparently cmake can autogenerate VC++ and Xcode project files from
the same thing that it builds from on unix systems.
cmake creating VC++ project files does not appeal much to me. First,
project files are not mandatory for using MS compiler.
cmake can create nmake files as well. It's also possible to add a different generator that use something else (even one that would output to gmake and use msvc compiler and gcc for header dependencies ).
For what it's worth, I think that using a system like cmake, while lessening the load of the LLVM developers, increases the load on users of LLVM. I'm building a piece of software and I have to deal with each external dependency using it's own favourite build system - the end result is that to build my software I have to use SCons, bjam, cmake, Visual Studio _and_ nmake.
In my opinion the best solution is if the software comes with project files/makefiles that are 'native' to the platform you're building on and doesn't require any extra software to be installed before you can build. I've had good results with using scripts to keep .vcproj files updated in order to synchronize project files between different versions of Visual Studio. The same method should be applicable to synchronizing with makefiles and XCode project files. If anything more complicated than adding/removing files need to be done, it can be done by hand - but that's pretty rare anyway.
For what it's worth, I think that using a system like cmake, while
lessening the load of the LLVM developers, increases the load on users of
LLVM.
Well if it is easy to use, i don't think that is a problem? Besides is
extendig llvm also an "use case" in this sense?
In my opinion the best solution is if the software comes with project
files/makefiles that are 'native' to the platform you're building on and
doesn't require any extra software to be installed before you can build.
I've had good results with using scripts to keep .vcproj files updated in
order to synchronize project files between different versions of Visual
Studio. The same method should be applicable to synchronizing with
makefiles and XCode project files. If anything more complicated than
adding/removing files need to be done, it can be done by hand - but that's
pretty rare anyway.
You are only talking only about specific development environments. I think
this is more problematic than a tool like cmake which can be used on every
plattform? Besides of that the scripting engine which does these
modifications needs also to be installed. So in the end it boils down to
personal preference which script language you have installed per default.
In my opinion the best solution is if the software comes with project
files/makefiles that are 'native' to the platform you're building on and
doesn't require any extra software to be installed before you can build.
I've had good results with using scripts to keep .vcproj files updated in
order to synchronize project files between different versions of Visual
Studio. The same method should be applicable to synchronizing with
makefiles and XCode project files. If anything more complicated than
adding/removing files need to be done, it can be done by hand - but that's
pretty rare anyway.
You are only talking only about specific development environments. I think this is more problematic than a tool like cmake which can be used on every plattform? Besides of that the scripting engine which does these modifications needs also to be installed. So in the end it boils down to personal preference which script language you have installed per default.
I think you misunderstood me, I meant running scripts on the subversion server when you check in that keeps the different project/makefiles in sync - Thus no problem for the developers or the users except the initial investment in creating the scripts and setting up the server.
I think you misunderstood me, I meant running scripts on the subversion
server when you check in that keeps the different project/makefiles in sync
- Thus no problem for the developers or the users except the initial
investment in creating the scripts and setting up the server.
Yes, i missunderstood you. I just think it is good to have a common easy
description which is able to do multi platform builds, than to create all
these scripts which may mess the directory's and are potential candidates for
bitrot. But well, i haven't to decide anyway :-).
).