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

Galina gkistanova at gmail.com
Fri Jan 9 12:03:36 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:
> 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?

http://reviews.llvm.org/D6867

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






More information about the llvm-commits mailing list