[PATCH] [zorg] Windows/Linux CMake builders for Hexagon using common getClangCMakeBuildFactory

Galina gkistanova at gmail.com
Fri Jan 9 15:11:21 PST 2015


REPOSITORY
  rL LLVM

================
Comment at: buildbot/osuosl/master/config/builders.py:401
@@ +400,3 @@
+                    # MSBuild command with user arguments.
+                    build_cmd=["MSBuild","/p:Configuration=RelWithDebInfo",
+                    "/maxcpucount", "ALL_BUILD.vcxproj"],
----------------
rfoos wrote:
> gkistanova wrote:
> > rfoos wrote:
> > > rengolin wrote:
> > > > Will we have to add this to the current builders, too?
> > > Yes the builder definition for a non-ninja build must pass everything in the command line.
> > > 
> > > This looks more difficult on the surface, but in fact it removes all the special case code from the builder. It is a much simpler way when you look at adding code to cover both windows and linux builds.
> > > 
> > > The default is correctly formed ninja that works on Linux. This goes with the original intent of the builder.
> > > 
> > > To use make or MSBuild or anything else the whole cmd line for each step is passed.
> > > 
> > > This eliminates the complexity of the MSVC factories.
> > > 
> > > The msbuild factories hardcoded or passed by argument the additional information for configuration (i.e. RelWithDebInfo), compiler version, environment, and targets/project files. (i.e. MSBuild doesn't use targets but rather named project files)
> > > 
> > > There's no real smart way to map "ninja install" to "MSBuild INSTALL.vcxproj" and many of the others.
> > > 
> > > Specifying everything in the command line arguments simplified everything.
> > > 
> > > --- additional planned change
> > > I will add jobs and loadaverage to the command line arguments too. These are supposed to be passed as properties defined by the buildslave. The current code has to change anyway.
> > > 
> > > The reason to move jobs/loadaverage out to the command line arguments are special -j/-l cases for make/ninja, lit, MSBuild, and Windows (warnings on loadaverage).
> > > 
> > > The logic for jobs/loadaverage brings back special case code, so it will move to the arguments, and the relevant commands will be loaded wrapped in WithProperties/Interpolate to allow any property to be used.
> > > 
> > The params seem generic enough and the same for all the similar VS builders.
> > How about defining them once for all the similar builders?
> > 
> I'm thinking you mean a wrapper builder that takes an existing VS builder and translates the arguments into a call to the generic cmake builder?
> 
> If so Yes!
> 
> After the current one is used by a few others, and is running production for 2 days. 
> 
> There are bound to be a few changes when others start using this, and waiting a short period would make testing a lot easier.
> 
> Wrapper builders that demonstrate some more complicated command lines would make it both easy to use, and serve as documentation for some more complicated use cases.
Yes, I was thinking of a wrapper builder.
And of course this is something which could wait till later.

The only potential challenge for wrapper builders I see is to make sure they will reload safely and correctly during the reconfig.

http://reviews.llvm.org/D6867

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list