Is there any special reason only x86 code is implemented in win32 folder unlike lib\Target folder which contains codes for other architectures?
Thank you.
Seung Jae Lee
Seung Jae Lee wrote:
Is there any special reason only x86 code is implemented in win32 folder unlike lib\Target folder which contains codes for other architectures?
No reason beyond the fact that windows is more or less only x86/x64. If you want to add more targets to the visual studio project files it shouldn't be very difficult. You can copy the custom build rules for the .td files in the x86 project. The rest is just adding the .cpp and .h files and setting the include paths etc. to the same as in the x86 project.
m.
Might I suggest the following tool for setting-up/maintaining the Visual Studio project files. It makes setting them up with all the right build options and include paths much, much easier. =)
It’s not clear it offers any real benefits. The project files already exist. To use this, I would have to throw them away and create new XML files by hand. I would have to maintain them by hand also, whereas the project files are maintainable from within Visual Studio, i.e. via an integrated GUI interface.
And to comment on supporting other targets: No reason it can’t be done, other than Windows doesn’t run on them, but be aware that they have never been compiled with VC++ and there may be issues with the code that need resolving before it successfully compiles with VC++.
Christopher Lamb wrote:
Jeff Cohen wrote:
It’s not clear it offers any real benefits. The project files already exist. To use this, I would have to throw them away and create new XML files by hand. I would have to maintain them by hand also, whereas the project files are maintainable from within Visual Studio, i.e. via an integrated GUI interface.
And one last comment… it also creates a dependency on yet another third party. The vast majority of Visual Studio users would not appreciate having to get xpj in order to maintain the project files.
I don’t want to drive this too off topic, but I should be clear that I wasn’t suggesting that the LLVM project adopt XPJ as it’s official config file format for Visual Studio. I have found it useful to use XPJ to generate the initial VS projects for a code base that doesn’t already have VS projects. I also find it nice to be able to see all of the config options in a flat, human readable file rather than a GUI, but this is certainly personal preference.
I don't want to drive this too off topic, but I should be clear that I
wasn't suggesting that the LLVM project adopt XPJ as it's official
config file format for Visual Studio. I have found it useful to use
XPJ to generate the initial VS projects for a code base that doesn't
already have VS projects. I also find it nice to be able to see all of
the config options in a flat, human readable file rather than a GUI,
but this is certainly personal preference.
We are more likely to adopt scons (via HLVM integration) than XPJ. Scons
provides a common build specification for all platforms (Win32, Unix,
MacOS, mainframe) and can also generate the Visual Studio files as
necessary. This would completely automate the process. As Unix
developers modify the Scons build scripts, the win32 directory could be
regenerated automatically and always kept current with the latest files,
etc. Hopefully this means Jeff never has to manually hack the VS files
again (although it won't relieve him of fixing the portability issues in
the code 
)
Don't hold your breath, getting scons working for LLVM is probably at
least a month off before it can reach "experimental" stage. I'm hoping I
can get it into the 2.0 release so people can try it (before we cut
over). I.e. the "make" and "scons" systems will co-exist for some time
period.
Reid.
Just to set expectations right:
Scons looks promising, but it is still in beta and we obviously aren't going to switch over to it unless we find it works out well for us. I don't think we should consider switching to scons for LLVM 2.0 (there is no user visible feature of it), but I think that having it available, in parallel with make, for 2.0 would be great. This would let people get experience with it, etc as reid said.
I have no expectation that scons won't work out, but if/when the migration happens, we want to make it as gentle as possible :), and let lots of people play with it first.
-Chris