|
1 SETUPPRJ.BAT |
|
2 ============ |
|
3 SETUPPRJ will create a BLD.BAT file in the GROUP directory and |
|
4 read the LI.PRJ file in other second-level directories, creating |
|
5 a BLD.BAT in each which will provide commands for building any |
|
6 .BAT, .PL and .PM files to \epoc32\tools. |
|
7 SETUPPRJ will also create \E32TOOLP\GROUP\E32TOOLP.REL |
|
8 |
|
9 PERLPREP.BAT |
|
10 ============ |
|
11 PERLPREP strips "use strict;" debugging lines out |
|
12 of .PL and .PM files and perl warning generation -w flag out of .BAT |
|
13 files. It is used for REL builds of E32TOOLP. |
|
14 |
|
15 RELEASING E32TOOLP |
|
16 ================== |
|
17 make changes to source |
|
18 change release.txt - update the date and "made by" details |
|
19 add any new files which contain a version number to setver.bat |
|
20 (remember perl files can use the service in E32TPVER.PM). |
|
21 cd \e32toolp\group |
|
22 run setver [version] to apply the latest version number. |
|
23 cd \e32toolp |
|
24 cvs commit to commit the version changes |
|
25 cd \e32toolp\group |
|
26 do setupprj to create the batch and .rel file |
|
27 do bld clean |
|
28 do bld rel |
|
29 Prep the tree for release to PVCS: |
|
30 cd \ |
|
31 perl \tools\pvcs-release.pl -f e32toolp |
|
32 Tag the modules you're releasing: |
|
33 cd \e32toolp |
|
34 cvs tag E32TOOLPvNNN |
|
35 Move the Latest-Release tag to the new files: |
|
36 cvs rtag -d Latest-Release e32toolp |
|
37 cvs rtag -r E32TOOLPvNNN Latest-Release e32toolp |
|
38 cd \e32toolp\group |
|
39 Create a vdiff.lis file with mnt difsrc <previous release> |
|
40 do set vcsid=BASETEAM |
|
41 do mnt lock to make sure BASETEAM has the lock for all li.prj files |
|
42 do mnt putsrc |
|
43 do mnt versrc |
|
44 do mnt putrel |
|
45 do set vcsid=<your vcsid> |
|
46 cd \e32toolp |
|
47 Tag the release as complete (on the main branch) |
|
48 cvs tag Release-NNN-complete |
|
49 go to the root of a clean drive |
|
50 getrel e32toolp tools <version> |
|
51 check it basically works - eg bldmake, makmake /mmp |
|
52 rd /s /q epoc32 |
|
53 pgetbld e32toolp group |
|
54 setupprj |
|
55 bld rel |
|
56 mnt valid |
|
57 check \e32toolp\valid.lis |
|
58 update Lotus Notes |
|
59 update tlmakmak.rtf |
|
60 |
|
61 OTHER INFO |
|
62 ========== |
|
63 CASE SENSITIVITY |
|
64 Perl pattern-matching is twice as quick if it's done case-sensitive - keep |
|
65 all data uppercase except when it's actually being outputted - at that point |
|
66 it can be formatted by doing something like ucfirst lc ... |
|
67 This is important so that pattern-matching done on data can assume |
|
68 uppercase. |
|
69 |
|
70 CPP |
|
71 cpp assumes with -M and -MG that missing user headers live in the same directory as the |
|
72 source while missing system headers live in the first system include directory specified. |
|
73 This is not in fact true. CPP always searches the directory containing the source file |
|
74 for headers if no user include path is specified explicitly. Then, and only then, if the |
|
75 -MG option is specified to -M cpp will just bang out the missing files without a path, |
|
76 whether or not they exist in the current directory or not. This means that if cpp is |
|
77 invoked in a makefile, (this probably applies to gcc too), cpp will fail unless these headers |
|
78 without a path exist in the working directory. |
|
79 |
|
80 cpp doesn't replace lines of text within #defines within other #defines |
|
81 with blank space if the lines aren't applicable for the current set of |
|
82 macros. This can upset makmake's reporting of correct line numbers for errors. |
|
83 |
|
84 cpp documentation states that a space is put at the end of a macro expansion |
|
85 "most of the time". We need to strip this back out after cpp has done its |
|
86 preprocessing in prepfile.pm. By expanding macros to themselves with three |
|
87 leading underscores we can tell where a macro has been expanded and strip |
|
88 the space added. |
|
89 |
|
90 MAKMAKE MODULE DESIGN |
|
91 the IDE/CL modules should provide |
|
92 a complete list of possible build variants and be designed in such a way that a particular |
|
93 implementation would not have to use all the builds if it didn't want to. I think this |
|
94 will be the case already. So, for example, if MISA could not do RELGDB the the CL_ARM code |
|
95 should never assume that all builds are required (except DEB or REL, which we must insist upon as a |
|
96 default in some cases). |
|
97 |
|
98 |
|
99 QUOTES IN MAKEFILES |
|
100 |
|
101 Must be consistent with quotes round long filenames. If remove quotes round .in |
|
102 file as a target to appease ar, the target will not be found and relgdb will not |
|
103 build. It seems that without the quotes the filename is parsed so the leading .\ |
|
104 on the front of the relgdb paths no longer makes a difference so rel and relgdb |
|
105 targets are considered the same. This means that rules for the rel and relgdb .in |
|
106 file, if it is around this target that the quotes are removed, and all subsequent |
|
107 dependencies and rules, will be done for each source file - eg gcc looks like it |
|
108 will be called twice with different flags. For the relgdb build nmake will complain |
|
109 that it doesn't know how to build the .in file because it sees it as a dependency of |
|
110 the main target with quotes and doesn't recognise it as the same thing appearing later |
|
111 as a target without quotes because the .\ is parsed out. The rel build doesn't complain |
|
112 because it has no preceding .\ to parse out. In short, filenames without quotes are parsed and |
|
113 amount to the same thing as filenames with quotes if the only difference between the two is the |
|
114 quotes and not the path itself. |
|
115 |
|
116 |
|
117 COMPILER FLAGS |
|
118 ============== |
|
119 |
|
120 ALL BUILDS |
|
121 /nologo - dont display the banner |
|
122 /Zp4 - Zp[n] - pack structs on n-byte boundary (whatever that means) /W4 - top level warnings |
|
123 /Fo<file> - specifies object file (left blank so base name taken from .cpp |
|
124 file) |
|
125 /c - compile only, don't link because we'll be linking later |
|
126 |
|
127 SPECIAL CASES |
|
128 |
|
129 /ML - Use run-time library -> Single-threaded (WINS exe release) /MD - Use run-time library -> Multi-threaded DLL (WINS dll release) |
|
130 these two flags have "d" appended for debug builds so that the respective debug run-time library is used instead. These flags are probably unnecessary for all projects not using Win32 libraries but MSVC puts them in by default, and it doesn't do any harm to have them I don't think |
|
131 |
|
132 /O1 - minimum size optimisation (WINS release) |
|
133 /Ob1 - disable inline function expansion (WINS release) (reason uncertain!) |
|
134 |
|
135 /Od - disable optimisations (WINS debug) |
|
136 |
|
137 /Zi - generate debugging info into program database (WINS debug) |
|
138 |
|
139 /FR - generate browse info (WINS debug) |
|
140 |
|
141 /Fd<file> - name program database (WINS debug) |
|
142 |
|
143 /X - suppresses searching of include directories specified by environmental |
|
144 include variable (so used for all projects not using Win32 services) |
|
145 |
|
146 |
|
147 LINKER FLAGS |
|
148 ============ |
|
149 |
|
150 ALL BUILDS |
|
151 /nologo - suppress startup banner /subsystem:windows - MSVC always puts this in anyway /machine:IX86 - ditto |
|
152 /out:<file> - specifies filename for target /WARN:3 - top-level warnings |
|
153 /nodefaultlib - don't use Win32 libraries (if any are being used then |
|
154 they are listed before this flag and so are not |
|
155 affected by it) |
|
156 |
|
157 SPECIAL CASES |
|
158 /baseaddress:<hex num> - base address for DLLs, specified by user /entry:"_E32Startup" - EPOC32 entry point for EXEs /entry:"_E32Dll" - EPOC32 entry point for DLLs |
|
159 |
|
160 /incremental:no - (WINS release) - presumably so a full-link is always |
|
161 performed |
|
162 /incremental:yes - (WINS debug) - presumably to save time linking-fully |
|
163 when working on a project |
|
164 |
|
165 /dll - (WINS dll targets) |
|
166 |
|
167 /pdb<file> - (WINS debug) <file> names program database |
|
168 |
|
169 /deffile:<file> - (WINS dll targets) <file> specifies a def file to |
|
170 refer to if one is specified by the user |
|
171 |
|
172 /implib:<file> - specifies name of import library to be created for dll |
|
173 targets if one is to be created |
|
174 |
|
175 /debug - (WINS debug) generates debugging information |
|
176 |
|
177 |
|
178 SOURCES OF INFORMATION FOR MAKMAKE ETC |
|
179 ====================================== |
|
180 NMAKE Reference in MSVC help |
|
181 Cygnus help files in R:\gcc\help - eg cpp.hlp |
|
182 Lotus notes - Epoc Software Design - Development Environment - suggestions |
|
183 for better build procedures |
|
184 Perl newsgroups |