[Bio] / askkb / Makefile Repository:
ViewVC logotype

Annotation of /askkb/Makefile

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.1 - (view) (download)

1 : olson 1.1 TOP_DIR = ../..
2 :     DEPLOY_RUNTIME ?= /kb/runtime
3 :     TARGET ?= /kb/deployment
4 :     SERVICE_SPEC = askkb.spec
5 :     SERVICE_PORT = 7072
6 :     SERVICE_NAME = askkb
7 :     #
8 :     # We need this while we transition services to the new naming convention -
9 :     # Makefile.common use $(SERVICE)
10 :     SERVICE = $(SERVICE_NAME)
11 :    
12 :     TPAGE_ARGS = --define kb_top=$(TARGET) \
13 :     --define kb_runtime=$(DEPLOY_RUNTIME) \
14 :     --define kb_service_name=$(SERVICE_NAME) \
15 :     --define kb_service_port=$(SERVICE_PORT) \
16 :     --define kb_psgi=$(SERVICE_NAME).psgi
17 :    
18 :     include $(TOP_DIR)/tools/Makefile.common
19 :    
20 :     # to wrap scripts and deploy them to $(TARGET)/bin using tools in
21 :     # the dev_container. right now, these vars are defined in
22 :     # Makefile.common, so it's redundant here.
23 :     TOOLS_DIR = $(TOP_DIR)/tools
24 :     WRAP_PERL_TOOL = wrap_perl
25 :     WRAP_PERL_SCRIPT = bash $(TOOLS_DIR)/$(WRAP_PERL_TOOL).sh
26 :     SRC_PERL = $(wildcard scripts/*.pl)
27 :    
28 :     # You can change these if you are putting your tests somewhere
29 :     # else or if you are not using the standard .t suffix
30 :     CLIENT_TESTS = $(wildcard client-tests/*.t)
31 :     SCRIPTS_TESTS = $(wildcard script-tests/*.t)
32 :     SERVER_TESTS = $(wildcard server-tests/*.t)
33 :    
34 :     # This is a very client-centric view of release engineering.
35 :     # We assume our primary product for the community is the client
36 :     # libraries, command line interfaces, and the related documentation
37 :     # from which specific science applications can be built.
38 :     #
39 :     # A service is composed of a client and a server, each of which
40 :     # should be independently deployable. Clients are composed of
41 :     # an application programming interface (API) and a command line
42 :     # interface (CLI). In our make targets, deploy-service deploys
43 :     # the server, deploy-client deploys the application
44 :     # programming interface libraries, and deploy-scripts deploys
45 :     # the command line interface (usually scripts written in a
46 :     # scripting language but java executables also qualify), and the
47 :     # deploy target would be equivelant to deploying a service (client
48 :     # libs, scripts, and server).
49 :     #
50 :     # Because the deployment of the server side code depends on the
51 :     # specific software module being deployed, the strategy needs
52 :     # to be one that leaves this decision to the module developer.
53 :     # This is done by having the deploy target depend on the
54 :     # deploy-service target. The module developer who chooses for
55 :     # good reason not to deploy the server with the client simply
56 :     # manages this dependancy accordingly. One option is to have
57 :     # a deploy-service target that does nothing, the other is to
58 :     # remove the dependancy from the deploy target.
59 :     #
60 :     # A smiliar naming convention is used for tests.
61 :    
62 :    
63 :     default: build-libs build-bin
64 :    
65 :     build-bin: $(BIN_PERL)
66 :    
67 :     # Test Section
68 :    
69 :     test: test-client test-scripts test-service
70 :     @echo "running client and script tests"
71 :    
72 :     # test-all is deprecated.
73 :     # test-all: test-client test-scripts test-service
74 :     #
75 :     # test-client: This is a test of a client library. If it is a
76 :     # client-server module, then it should be run against a running
77 :     # server. You can say that this also tests the server, and I
78 :     # agree. You can add a test-service dependancy to the test-client
79 :     # target if it makes sense to you. This test example assumes there is
80 :     # already a tested running server.
81 :     test-client:
82 :     # run each test
83 :     for t in $(CLIENT_TESTS) ; do \
84 :     if [ -f $$t ] ; then \
85 :     $(DEPLOY_RUNTIME)/bin/perl $$t ; \
86 :     if [ $$? -ne 0 ] ; then \
87 :     exit 1 ; \
88 :     fi \
89 :     fi \
90 :     done
91 :    
92 :     # test-scripts: A script test should test the command line scripts. If
93 :     # the script is a client in a client-server architecture, then there
94 :     # should be tests against a running server. You can add a test-service
95 :     # dependency to the test-client target. You could also add a
96 :     # deploy-service and start-server dependancy to the test-scripts
97 :     # target if it makes sense to you. Future versions of the makefiles
98 :     # for services will move in this direction.
99 :     test-scripts:
100 :     # run each test
101 :     for t in $(SCRIPT_TESTS) ; do \
102 :     if [ -f $$t ] ; then \
103 :     $(DEPLOY_RUNTIME)/bin/perl $$t ; \
104 :     if [ $$? -ne 0 ] ; then \
105 :     exit 1 ; \
106 :     fi \
107 :     fi \
108 :     done
109 :    
110 :     # test-service: A server test should not rely on the client libraries
111 :     # or scripts--you should not have a test-service target that depends
112 :     # on the test-client or test-scripts targets. Otherwise, a circular
113 :     # dependency graph could result.
114 :     test-service:
115 :     # run each test
116 :     for t in $(SERVER_TESTS) ; do \
117 :     if [ -f $$t ] ; then \
118 :     $(DEPLOY_RUNTIME)/bin/perl $$t ; \
119 :     if [ $$? -ne 0 ] ; then \
120 :     exit 1 ; \
121 :     fi \
122 :     fi \
123 :     done
124 :    
125 :     # Deployment:
126 :     #
127 :     # We are assuming our primary products to the community are
128 :     # client side application programming interface libraries and a
129 :     # command line interface (scripts). The deployment of client
130 :     # artifacts should not be dependent on deployment of a server,
131 :     # although we recommend deploying the server code with the
132 :     # client code when the deploy target is executed. If you have
133 :     # good reason not to deploy the server at the same time as the
134 :     # client, just delete the dependancy on deploy-service. It is
135 :     # important to note that you must have a deploy-service target
136 :     # even if there is no server side code to deploy.
137 :    
138 :     deploy: deploy-client deploy-service
139 :    
140 :     # deploy-all deploys client *and* server. This target is deprecated
141 :     # and should be replaced by the deploy target.
142 :    
143 :     deploy-all: deploy-client deploy-service
144 :    
145 :     # deploy-client should deploy the client artifacts, mainly
146 :     # the application programming interface libraries, command
147 :     # line scripts, and associated reference documentation.
148 :    
149 :     deploy-client: deploy-libs deploy-scripts deploy-docs
150 :    
151 :     # The deploy-libs and deploy-scripts targets are used to recognize
152 :     # and delineate the client types, mainly a set of libraries that
153 :     # implement an application programming interface and a set of
154 :     # command line scripts that provide command-based execution of
155 :     # individual API functions and aggregated sets of API functions.
156 :    
157 :     deploy-libs: build-libs
158 :     rsync --exclude '*.bak*' -arv lib/. $(TARGET)/lib/.
159 :    
160 :     # Deploying scripts needs some special care. They need to run
161 :     # in a certain runtime environment. Users should not have
162 :     # to modify their user environments to run kbase scripts, other
163 :     # than just sourcing a single user-env script. The creation
164 :     # of this user-env script is the responsibility of the code
165 :     # that builds all the kbase modules. In the code below, we
166 :     # run a script in the dev_container tools directory that
167 :     # wraps perl scripts. The name of the perl wrapper script is
168 :     # kept in the WRAP_PERL_SCRIPT make variable. This script
169 :     # requires some information that is passed to it by way
170 :     # of exported environment variables in the bash script below.
171 :     #
172 :     # What does it mean to wrap a perl script? To wrap a perl
173 :     # script means that a bash script is created that sets
174 :     # all required environment variables and then calls the perl
175 :     # script using the perl interperter in the kbase runtime.
176 :     # For this to work, both the actual script and the newly
177 :     # created shell script have to be deployed. When a perl
178 :     # script is wrapped, it is first copied to TARGET/plbin.
179 :     # The shell script can now be created because the necessary
180 :     # environment variables are known and the location of the
181 :     # script is known.
182 :    
183 :     deploy-scripts:
184 :     export KB_TOP=$(TARGET); \
185 :     export KB_RUNTIME=$(DEPLOY_RUNTIME); \
186 :     export KB_PERL_PATH=$(TARGET)/lib bash ; \
187 :     for src in $(SRC_PERL) ; do \
188 :     basefile=`basename $$src`; \
189 :     base=`basename $$src .pl`; \
190 :     @echo install $$src $$base ; \
191 :     cp $$src $(TARGET)/plbin ; \
192 :     $(WRAP_PERL_SCRIPT) "$(TARGET)/plbin/$$basefile" $(TARGET)/bin/$$base ; \
193 :     done
194 :    
195 :     # Deploying a service refers to to deploying the capability
196 :     # to run a service. Because service code is often deployed
197 :     # as part of the libs, meaning service code gets deployed
198 :     # when deploy-libs is called, the deploy-service target is
199 :     # generally concerned with the service start and stop scripts.
200 :    
201 :     deploy-service: deploy-dir-service deploy-monit deploy-libs
202 :     $(TPAGE) $(TPAGE_ARGS) service/start_service.tt > $(TARGET)/services/$(SERVICE_NAME)/start_service
203 :     chmod +x $(TARGET)/services/$(SERVICE_NAME)/start_service
204 :     $(TPAGE) $(TPAGE_ARGS) service/stop_service.tt > $(TARGET)/services/$(SERVICE_NAME)/stop_service
205 :     chmod +x $(TARGET)/services/$(SERVICE_NAME)/stop_service
206 :    
207 :     deploy-monit:
208 :     $(TPAGE) $(TPAGE_ARGS) service/process.tt > $(TARGET)/services/$(SERVICE_NAME)/process.$(SERVICE_NAME)
209 :    
210 :     # Deploying docs here refers to the deployment of documentation
211 :     # of the API. We'll include a description of deploying documentation
212 :     # of command line interface scripts when we have a better understanding of
213 :     # how to standardize and automate CLI documentation.
214 :    
215 :     deploy-docs: build-docs
216 :     -mkdir -p $(TARGET)/services/$(SERVICE_NAME)/webroot/.
217 :     cp docs/*.html $(TARGET)/services/$(SERVICE_NAME)/webroot/.
218 :    
219 :     # The location of the Client.pm file depends on the --client param
220 :     # that is provided to the compile_typespec command. The
221 :     # compile_typespec command is called in the build-libs target.
222 :    
223 :     build-docs: compile-docs
224 :     -mkdir docs
225 :     pod2html --infile=lib/Bio/KBase/$(SERVICE_NAME)/Client.pm --outfile=docs/$(SERVICE_NAME).html
226 :    
227 :     # Use the compile-docs target if you want to unlink the generation of
228 :     # the docs from the generation of the libs. Not recommended, but there
229 :     # could be a reason for it that I'm not seeing.
230 :     # The compile-docs target should depend on build-libs so that we are
231 :     # assured of having a set of documentation that is based on the latest
232 :     # type spec.
233 :    
234 :     compile-docs: build-libs
235 :    
236 :     # build-libs should be dependent on the type specification and the
237 :     # type compiler. Building the libs in this way means that you don't
238 :     # need to put automatically generated code in a source code version
239 :     # control repository (e.g., cvs, git). It also ensures that you always
240 :     # have the most up-to-date libs and documentation if your compile-docs
241 :     # target depends on the compiled libs.
242 :    
243 :     build-libs:
244 :     compile_typespec \
245 :     --psgi $(SERVICE_NAME).psgi \
246 :     --impl Bio::KBase::$(SERVICE_NAME)::$(SERVICE_NAME)Impl \
247 :     --service Bio::KBase::$(SERVICE_NAME)::Service \
248 :     --client Bio::KBase::$(SERVICE_NAME)::Client \
249 :     --py biokbase/$(SERVICE_NAME)/Client \
250 :     --js javascript/$(SERVICE_NAME)/Client \
251 :     --url http://kbase.us/services/phispy \
252 :     $(SERVICE_SPEC) lib
253 :    
254 :     -rm -r Bio
255 :    
256 :     include $(TOP_DIR)/tools/Makefile.common.rules

MCS Webmaster
ViewVC Help
Powered by ViewVC 1.0.3