x86 in win32 folder

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

x86 in win32 folder

Seung Jae Lee
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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: x86 in win32 folder

Morten Ofstad
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.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: x86 in win32 folder

Christopher Lamb
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. =)


--
Christopher Lamb


On Mar 28, 2007, at 3:06 AM, Morten Ofstad wrote:

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.
_______________________________________________
LLVM Developers mailing list


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: x86 in win32 folder

Jeff Cohen
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:
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. =)


--
Christopher Lamb


On Mar 28, 2007, at 3:06 AM, Morten Ofstad wrote:

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.
_______________________________________________
LLVM Developers mailing list


_______________________________________________ LLVM Developers mailing list [hidden email] http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: x86 in win32 folder

Jeff Cohen
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.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: x86 in win32 folder

Christopher Lamb
In reply to this post by Jeff Cohen
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.

On Mar 28, 2007, at 9:46 AM, 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 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:
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. =)


--
Christopher Lamb


On Mar 28, 2007, at 3:06 AM, Morten Ofstad wrote:

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.
_______________________________________________
LLVM Developers mailing list


_______________________________________________ LLVM Developers mailing list [hidden email] http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
_______________________________________________
LLVM Developers mailing list

--
Christopher Lamb



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: x86 in win32 folder

Reid Spencer-2
On Wed, 2007-03-28 at 10:22 -0500, Christopher Lamb wrote:
> 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.

>
> On Mar 28, 2007, at 9:46 AM, 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 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:
> > > 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. =)
> > >
> > >
> > > http://sourceforge.net/projects/xpj
> > >
> > > --
> > > Christopher Lamb
> > > [hidden email]
> > >
> > >
> > >
> > > On Mar 28, 2007, at 3:06 AM, Morten Ofstad wrote:
> > >
> > > > 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.
> > > > _______________________________________________
> > > > LLVM Developers mailing list
> > > > [hidden email]         http://llvm.cs.uiuc.edu
> > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > >
> > >
> > > __________________________________________________________________
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > [hidden email]         http://llvm.cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > >  
> > _______________________________________________
> > LLVM Developers mailing list
> > [hidden email]         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> --
> Christopher Lamb
> [hidden email]
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: x86 in win32 folder

Chris Lattner
On Wed, 28 Mar 2007, Reid Spencer wrote:
> 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,

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

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev