[Bio] / askkb / Makefile Repository:
ViewVC logotype

Annotation of /askkb/Makefile

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.2 - (view) (download)

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

MCS Webmaster
ViewVC Help
Powered by ViewVC 1.0.3