[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: include doc and RPM build process in origin-server file tree?



You also need to handle chain dependencies (site => console) - that's fairly annoying now although you can steal the code for resolving that dep order from origin-dev-tools or hardcode it.

----- Original Message -----
> Recently I've been writing up what it takes for someone who wants to
> build the origin-server packages on their own.  The nuts and bolts
> of finding the root of each RPM directory and (one way of)
> identifying the list of build dependencies is posted at
> http://cloud-mechanic.blogspot.com/2013/03/the-bleeding-edge-building-openshift.html
> 
> devenv will do all three of these tasks (install dependencies, build
> RPMs, generate docs) but it seems strange to me that I *need* a
> additional tool (meant to generate AMIs for testing) just to build
> the RPMs and yum repo. I think that we may already have tools in
> place that with a little work would automate these tasks without
> requiring an additional non-standard tool. In fact, Krishna's
> already done some of this in the Rakefile at the top of the tree.
>  There's a target there named doc:gen that will walk the entire
> source tree and generate yardoc documentation, placing it in a
> location at the top of the tree.
> 
> My first inclination is that comparable targets for gems (where
> applicable) and rpms would make the build process more intuitive for
> people who want or need to build the packages but do not need all of
> the additional aspects of building AMIs or liveCD images.
> 
> 
> I've put together a quartet of rake tasks that, if placed in the root
> of the right directories could be used to get the effect I'm looking
> for.  It would not be hard to write a task at the root that would
> call these for all package trees.
> 
> --------------------------
> ...
> 
> require 'yard'
> desc "Generate documentation"
> YARD::Rake::YardocTask.new() do |t|
>   docdir = ENV['docdir']
>   if not docdir == nil
>     t.options = ["--output-dir", docdir]
>   end
> end
> 
> #
> # Install build requirements
> #
> # Use sudo(1) if caller is not root
> #
> desc "Install build dependencies for this package"
> task :builddep, :answer do |t, args|
>   specfiles = Dir.glob("*.spec")
>   if specfiles.length != 1 then
>     raise Exception.new("there must be exactly one specfile")
>   end
>   builddep_cmd = "yum-builddep #{specfiles[0]}"
>   if not args['answer'] == nil then
>     if not ['yes', 'no'].include? args['answer']
>       raise Exception.new("builddep answer must be 'yes' or 'no'")
>     end
>     builddep_cmd += " --assume#{args['answer']}"
>   end
>   builddep_cmd = "sudo " + builddep_cmd if not Process.uid == 0
>   system builddep_cmd
> end
> 
> 
> desc "Create installable RPM package"
> task :rpm, :test do |t, args|
>   build_cmd = "tito build --rpm"
> 
>   repodir = ENV['repodir']
>   if repodir then
>     if not repodir == nil && (not File.exists? repodir) then
>       raise Exception.new("RPM directory does not exist")
>     end
>     build_cmd += "--output #{repodir}"
>   end
> 
>   if args[:test] then
>     build_cmd += " --test"
>   end
>   system build_cmd
> end
> 
> desc "Create installable RPM package for testing"
> task :testrpm do
>   Rake.application.invoke_task("rpm[true]")
> end
> 
> 
> ---
> 
> A set of tasks in the top Rakefile which would find and invoke those
> further down in the tree would make rebuilding single components or
> the whole tree a fairly simple matter, both self-contained and
> consistant:
> 
> rake yard - generate docs here (and below)
> rake rpm  - generate the most recent tagged package
> rake testrpm - generate a test package or packages
> 
> 
> Upsides:
> 
> * use existing well known tools
> * remove complexity from devenv (let it do what it does well)
> * consistent task method (you want to X, use rake)
> * ability to work at the appropriate scale (build one, build all)
> * task code is kept close to the source code (allows customization as
> needed: pam_openshift?)
> 
> Downsides:
> 
> * global changes to build tasks require changes in each RPM root.
> * "duplicates" functions already in devenv
> * install build dependencies requires one call per RPM (likely
> duplication)
> 
> Comments? Other suggestions?
> 
> - Mark
> 
> --
> Mark Lamourine <markllama redhat com>
> Sr. Software Developer, Cloud Engineering
> Red Hat, 314 Littleton Road, Westford MA 01886
> Voice: +1 978 392 1093
> http://people.redhat.com/~mlamouri
> markllama @ irc://irc.freenod.org*lopsa
> 
> _______________________________________________
> dev mailing list
> dev lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]