llvm dev - Mar 2007 - [LLVMdev] x86 in win32 folder

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. =)
>>
>> http://sourceforge.net/projects/xpj
>>
>> --
>> Christopher Lamb
>> christopher.lamb at gmail.com
>>
>>
>> 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
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
--
Christopher Lamb
christopher.lamb at gmail.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20070328/e01a4321/attachment.html>

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
> > > christopher.lamb at gmail.com
> > > 
> > > 
> > > 
> > > 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
> > > > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > > 
> > > 
> > >
__________________________________________________________________
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > >   
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> --
> Christopher Lamb
> christopher.lamb at gmail.com
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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/