aboutsummaryrefslogtreecommitdiffstats
path: root/Configurations/common.tmpl
Commit message (Collapse)AuthorAgeFilesLines
* Build: Remove BEGINRAW / ENDRAW / OVERRIDERichard Levitte2019-01-311-4/+0
| | | | | | | | | | It was an ugly hack to avoid certain problems that are no more. Also added GENERATE lines for perlasm scripts that didn't have that explicitly. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8125)
* Build: change remaining $unified_info{install} checks to use attributesRichard Levitte2019-01-221-24/+12
| | | | | Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8063)
* Build: pass attributes down to make rule generatorsRichard Levitte2019-01-221-0/+5
| | | | | | | | | For good measure, we pass down attributes when calling obj2shlib, obj2lib, obj2dso, obj2bin, or in2script. We currently don't use them in our build file templates, but might as well for future use. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7581)
* Rework building: Get rid of old %unified_info structuresRichard Levitte2019-01-211-2/+1
| | | | | | | | | | | | Now that we have the names of libraries on different systems established through platform modules, we can remove the old structure to establish the same thing, i.e. $unified_info{sharednames} and $unified_info{rename}. That means removing support for the RENAME and SHARED_NAME keywords in build.info as well. Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/7473)
* Build: Make it possible to have defines assigned to end products as wellRichard Levitte2018-11-051-2/+4
| | | | | | | | | | | | | | | This simple fix allows the following construct: PROGRAMS=foo SOURCE[foo]=foo.c bar.c DEFINE[foo]=FOO=1 BAR=0 These will trickle down to the build of object files, so building foo.o and bar.o will be done with these options: -DFOO=1 -DBAR=0 (exact syntax depending on platform, of course) Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/7553)
* Build: make it possible to assign macro definitions for specific outputsRichard Levitte2018-11-051-0/+2
| | | | | | | | Sometimes, some specific program or object file might need an extra macro definition of its own. This allows that to be easily done. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/7553)
* Configuration: when building the dirinfo structure, include shared_sourcesRichard Levitte2018-10-311-41/+0
| | | | | | | | | | | This makes sure that any resulting directory target in the build files also depend on object files meant for shared libraries. As a side effect, we move the production of the dirinfo structure from common.tmpl to Configure, to make it easier to check the result. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7452)
* Add build file support for generic symbol exports with DSOsRichard Levitte2018-10-051-1/+8
| | | | | Reviewed-by: Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7347)
* VMS: stop trying to build shared libraries from static onesRichard Levitte2018-09-131-2/+3
| | | | | | | | | | | | | The possibility to do this was killed when we started producing object file names with encoded intention (and possibly different builds), and leads to build errors. With that, 'libobj2shlib' is renamed to 'obj2shlib' to reflect this design change. The old name is still used if the new one isn't available, for the sake of backward compatibility. Reviewed-by: Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7198)
* Build files: Separate 'lib' intent from 'shlib' intentRichard Levitte2018-09-121-1/+1
| | | | | | | | | This is in preparation for having separate CFLAGS variables for static and for shared library builds. Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7159)
* Configure: Name object files according to the product they are part ofRichard Levitte2018-09-121-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | This will allow to have different object files for different products, even if they share the same source code, and possibly different builds for those different object files. For example, one can have something like this: SOURCES[libfoo]=cookie.c INCLUDES[libfoo]=include/foo SOURCES[libbar]=cookie.c INCLUDES[libbar]=include/bar This would mean that the object files and libraries would be build somewhat like this: $(CC) -Iinclude/foo -o libfoo-lib-cookie.o cookie.c $(AR) $(ARFLAGS) libfoo.a libfoo-lib-cookie.o $(CC) -Iinclude/bar -o libbar-lib-cookie.o cookie.c $(AR) $(ARFLAGS) libbar.a libbar-lib-cookie.o Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7159)
* Configure: DON'T trickle down includes from products to sourcesRichard Levitte2018-09-121-2/+4
| | | | | | | | | | Instead, use the include settings from the products later in the process, making it possible to have different includes for two different libraries that share the same source code. Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7159)
* Configure: let INCLUDEs set on binaries "trickle down" to the objectsRichard Levitte2018-01-241-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | This ensures that only one set of includes is associated with each object file, reagardless of where it's used. For example, if apps/build.info has this: SOURCE[openssl]=foo.c INCLUDE[openssl]=.. ../include and test/build.info has this: SOURCE[footest]=../apps/foo.c INCLUDE[footest]=../include The inclusion directories used for apps/foo.o would differ depending on which program's dependencies get generated first in the build file. With this change, all those INCLUDEs get combined into one set of inclusion directories tied to the object file. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5153)
* Configure et al: cleanupsRichard Levitte2017-12-121-5/+1
| | | | | | | | | | | | | | | | | | | | Remove some config attributes that just duplicate values that are already there in other attributes. Remove the special runs of mkdef.pl and mkrc.pl from build file templates, as these are now done via GENERATE statements in build.info. Remove all references to ordinal files from build file templates, as these are now treated via the GENERATE statements in build.info. Also remove -shared flags and similar that are there in shared-info.pl anyway. (in the case of darwin, it's mandatory, as -bundle and -dynamiclib don't mix) Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4840)
* Build file templates: Replace the use of Makefile.sharedRichard Levitte2017-12-121-14/+16
| | | | | | | | | | | | | | | | | | | | | | | | | Because this also includes handling all sorts of non-object files when linking a program, shared library or DSO, this also includes allowing general recognition of files such as .res files (compiled from .rc files), or .def / .map / .opt files (for export and possibly versioning of public symbols only). This does mean that there's a tangible change for all build file templates: they must now recognise and handle the `.o` extension, which is used internally to recognise object files internally. This extension was removed by common.tmpl before this change, but would mean that the platform specific templates wouldn't know if "foo.map" was originally "foo.map.o" (i.e. an object file in its own right) or "foo.map" (an export definition file that should be treated as such, not as an object file). For the sake of simplifying things, we also modify util/mkdef.pl to produce .def (Windows) and .opt (VMS) files that don't need additional hackery. Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4840)
* Many spelling fixes/typo's corrected.Josh Soref2017-11-111-1/+1
| | | | | | | | | Around 138 distinct errors found and fixed; thanks! Reviewed-by: Kurt Roeckx <kurt@roeckx.be> Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3459)
* Make it possible to build static-only librariesRichard Levitte2017-04-241-5/+15
| | | | | | The trick is to use the .a extension explicitely in the build.info files. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3243)
* VMS: Fix the passing of cflags for things not being installedRichard Levitte2017-04-181-1/+1
| | | | | | | | | | | When building object files for libraries, information whether the library would be installed or not wasn't passed down to the object file building rules. Also, make it so settings like |no_inst_lib_cflags| can be the empty string. Reviewed-by: Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3247)
* Building: make it possible to force linking with static OpenSSL libsRichard Levitte2016-11-101-3/+11
| | | | | | | | | Very simply, support having the .a extension to denote depending on static libraries. Note that this is not supported on native Windows when building shared libraries, as there is not static library then, just an import library with the same name. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1889)
* Build file templates: additional information to build file template functionsRichard Levitte2016-09-091-6/+23
| | | | | | | | | | Send a bit information to the build file template functions. For src2obj(), the additional option 'product' holds the name of the final file that the object file will go into. Additionally, the diverse functions will get the option 'installed', with a value that evaluates true if the final product is to be installed, otherwise false. Reviewed-by: Rich Salz <rsalz@openssl.org>
* Configure: Make it possible to generate mandatory header filesRichard Levitte2016-06-141-0/+3
| | | | | | | | | | 'DEPEND[]=file.h' becomes a special way to say that 'file.h' must be generated before anything else is built. It's likely that a number of source files depend on these header files, this provides a simple way to make sure they are always generated even it the dependency data hasn't been added to the build file yet. Reviewed-by: Rich Salz <rsalz@openssl.org>
* Fix the directory target generationRichard Levitte2016-06-061-2/+14
| | | | | | | | | | | | | | The directories for the final products were never registered, it was plain luck that intermediary files were in the same place and registered the directory anyway. Also, scripts are generated directly from source (binaries go through intermadiary object files), so we need to explicitely make sure to avoid registering the source directory unless it's an in source build. Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
* Add developer targets for each subdirectory we have something to build inRichard Levitte2016-06-041-2/+44
| | | | | | | | | | | | | | | | | | | Previous build scheme allowed building just the stuff in one subdirectory, like this: make -C crypto/aes Because the unified only has a top-level Makefile, this is not possible with it. This change adds a replacement where each directory we have something to build in becomes a target in its own right, allowing building something like this: make crypto/aes The exception is the directory test, because we already have such a target. Reviewed-by: Stephen Henson <steve@openssl.org>
* Communicate Configure generated header files to build filesRichard Levitte2016-05-251-0/+2
| | | | | | | | | Add Configure generated header files to $unified_info{generate}. This makes sure the build files will pick them up with the rest for the GENERATED macro, and thereby make sure they get cleaned away by 'make clean' Reviewed-by: Rich Salz <rsalz@openssl.org>
* Build system: add include directories and dependencies for generatorsRichard Levitte2016-04-251-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | In the case of generating a file like this: GENERATE[foo.S]=mkfoo.pl arg1 arg2 the 'mkfoo.pl' generator itself might need to include other files, such as perl modules within our source tree. We can reuse already existing syntax for it, like this: INCLUDE[mkfoo.pl]=module/path or: DEPEND[mkfoo.pl]=modules/mymodule.pm This change implements the support for such constructs, and for the DEPEND statement, for any value that indicates a perl module (.pm file), it will automatically infer an INCLUDE statement for its directory, just like it does for C header files, so you won't have do write this: DEPEND[mkfoo.pl]=modules/mymodule.pm INCLUDE[mkfoo.pl]=modules Reviewed-by: Emilia Käsper <emilia@openssl.org>
* Perl: foreach (@list) { code } is betterRichard Levitte2016-04-061-4/+4
| | | | Reviewed-by: Emilia Käsper <emilia@openssl.org>
* Perl cleanup: don't create lists unnecessarilyRichard Levitte2016-04-061-10/+18
| | | | Reviewed-by: Rich Salz <rsalz@openssl.org>
* Make it possible to specify source files that will only be used for shared libsRichard Levitte2016-03-301-3/+7
| | | | | | | | | | There are rare cases when an object file will only be used when building a shared library. To enable this, we introduce SHARED_SOURCE: SHARED_SOURCE[libfoo]=dllmain.c Reviewed-by: Andy Polyakov <appro@openssl.org>
* Pass down inclusion directories to source file generatorsRichard Levitte2016-03-101-2/+9
| | | | | | | | | | The source file generators sometimes use $(CC) to post-process generated source, and getting the inclusion directories may be necessary at times, so we pass them down. RT#4406 Reviewed-by: Rich Salz <rsalz@openssl.org>
* Unified - Add the build.info command OVERRIDE, to avoid build file clashesRichard Levitte2016-03-071-0/+3
| | | | | | | | | | | | | | | | Should it be needed because the recipes within a RAW section might clash with those generated by Configure, it's possible to tell it not to generate them with the use of OVERRIDES, for example: SOURCE[libfoo]=foo.c bar.c OVERRIDES=bar.o BEGINRAW[Makefile(unix)] bar.o: bar.c $(CC) $(CFLAGS) -DSPECIAL -c -o $@ $< ENDRAW[Makefile(unix)] Reviewed-by: Rich Salz <rsalz@openssl.org>
* Unified - Add the build.info command GENERATE, to generate source filesRichard Levitte2016-03-071-1/+21
| | | | | | | | | | | | | | | | In some cases, one might want to generate some source files from others, that's done as follows: GENERATE[foo.s]=asm/something.pl $(CFLAGS) GENERATE[bar.s]=asm/bar.S The value of each GENERATE line is a command line or part of it. Configure places no rules on the command line, except the the first item muct be the generator file. It is, however, entirely up to the build file template to define exactly how those command lines should be handled, how the output is captured and so on. Reviewed-by: Rich Salz <rsalz@openssl.org>
* Keep a cache of files that already have a recipe, in common.tmplRichard Levitte2016-02-271-1/+12
| | | | | | We don't want recipes for the same files generated more than once Reviewed-by: Rich Salz <rsalz@openssl.org>
* Clean away $config{no_shared} since we have $disabled{shared}Richard Levitte2016-02-221-1/+1
| | | | Reviewed-by: Rich Salz <rsalz@openssl.org>
* Always build library object files with shared library cflagsRichard Levitte2016-02-201-2/+4
| | | | | | | | | | | | | | | | This takes us away from the idea that we know exactly how our static libraries are going to get used. Instead, we make them available to build shareable things with, be it other shared libraries or DSOs. On the other hand, we also have greater control of when the shared library cflags. They will never be used with object files meant got binaries, such as apps/openssl or test/test*. With unified, we take this a bit further and prepare for having to deal with extra cflags specifically to be used with DSOs (dynamic engines), libraries and binaries (applications). Reviewed-by: Rich Salz <rsalz@openssl.org>
* Small rename fest in unified, obj2dynlib -> obj2dsoRichard Levitte2016-02-191-5/+5
| | | | | | | Since we're using the acronym DSO everywhere else and that's a common name for that kind of object, we might as well do so here as well. Reviewed-by: Andy Polyakov <appro@openssl.org>
* Don't treat .d (depend) files separately from object filesRichard Levitte2016-02-181-5/+0
| | | | | | | | | | | | | .d (.MMS in the VMS world) files with just dependencies are built from exactly the same conditions as the object files. Therefore, the rules for them can be built at the same time as the rules for the corresponding object files. This removes the requirement for a src2dep function in the build file templates, and for common.tmpl to call it. In the end, the existence of depend files is entirely up to the build file. Reviewed-by: Rich Salz <rsalz@openssl.org>
* Unified build - fix make dependRichard Levitte2016-02-121-0/+1
| | | | | | | | | | | | There was a catch 22, where 'make depend' directly after configuring in an otherwise pristine build tree would fail because buildinf.h didn't exist yet. This change has the depend building targets depend on the same other targets as the object file building targets, so the generation of buildinf.h and similar files would kick in during 'make depend'. Reviewed-by: Rich Salz <rsalz@openssl.org>
* unified build scheme: add and document the "unified" driving engineRichard Levitte2016-02-091-0/+118
common.tmpl will be used together with the template build file, and is the engine that connects the information gathered from all the build.info files with making the build file itself. This file expects there to be a template section in the build file template that defines a number perl functions designed to return strings with appropriate lines for the build system at hand. The exact functions, what they can expect as arguments and what output they're expected to produce is documented in Configurations/README. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-27 09:40:41 +0000