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>
This applies when building out-of-source.
RT#4486
NOTE: we can't do the same for Unix, as Unix make doesn't handle this
type of issue. Also, directory specs are much less likely to have
spaces on Unix...
Reviewed-by: Matt Caswell <matt@openssl.org>
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>
- some Perl versions are allergic to missing ';';
- don't stop if del fails;
- omit unused environment variable;
Reviewed-by: Stephen Henson <steve@openssl.org>
If environment variables are not explanded early enough, expanded
strings are passed with single backslash to C compiler, e.g.
C:\Program Files, which effectively results in OpenSSL looking for
engines and certificates in C:Program Files.
Reviewed-by: Richard Levitte <levitte@openssl.org>
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>
Because we have a directory 'test', the target 'test' may be confusing
to make. However, if we make it depend on 'tests', which doesn't
exist, make should never fail to run the actions.
Reviewed-by: Andy Polyakov <appro@openssl.org>
no-stdio does not work with the apps. Since the tests also need the apps
it doesn't support that either. Therefore we disable building of both.
no-autoalginit is not compatible with the apps because it requires explicit
loading of the algorithms, and the apps don't do that. Therefore we disable
building the apps for this option. Similarly the tests depend on the apps
so we also disable the tests. Finally the whole point about no-autoalginit
is to avoid excessive executable sizes when doing static linking. Therefore
we disable "shared" if this option is selected.
Reviewed-by: Richard Levitte <levitte@openssl.org>
The handling was Unix centric, already in Configure. Change that to
just collect the value and let the build file templates figure out
what to do with it.
Reviewed-by: Matt Caswell <matt@openssl.org>
Without proper cleanup after DLL link failure second attempt to
run nmake would actually proceed and failure will be "shifted" to
run time. This is because libcrypto.lib import library is generated
even if DLL link fails.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Previously, we updated the static libraries (libcrypto.a on Unix,
libcrypto.lib on Windows) with all the object files, regardless of if
they were rebuilt or not. With this change, we only update them with
the object files were rebuilt.
NOTE: this does not apply on VMS, as the expansion of $? may be too
large for a command line.
Reviewed-by: Andy Polyakov <appro@openssl.org>
utils/mkrc.pl was added a while ago as a better generator for the
Windows DLL resource file. Finalize the change by removing the
ms/version32.rc generator from Configure and adding resource file
support using mkrc.pl in Configurations/windows-makefile.pl
Reviewed-by: Andy Polyakov <appro@openssl.org>
generatesrc() did already receive dependency information, but never
used it, and never really needed to... until now.
Reviewed-by: Rich Salz <rsalz@openssl.org>
On Windows, we set INSTALLTOP to default as follows:
VC-WIN32:
PREFIX: %ProgramFiles(x86)%\OpenSSL
OPENSSLDIR: %CommonProgramFiles(x86)%\SSL
VC-WIN64*:
PREFIX: %ProgramW6432%\OpenSSL
OPENSSLDIR: %CommonProgramW6432%\SSL
Should those environment variables be missing, the following is used
as fallback:
PREFIX: %ProgramFiles%\OpenSSL
OPENSSLDIR: %CommonProgramFiles%\SSL
Reviewed-by: Andy Polyakov <appro@openssl.org>
util/mkdef.pl assumes it knows what the resulting library name will
be. Really, it shouldn't, but changing it will break classic native
Windows builds, so we leave it for now and change the LIBRARY line
externally when needed instead.
Reviewed-by: Matt Caswell <matt@openssl.org>
The variable SHARED_CFLAGS and SHARD_LDFLAGS were used in the Unix
template because they normally contain options used when building
"shared". The Windows template, on the other hand, uses LIB_CFLAGS,
to express the intended use of those flags rather than their content.
The Windows template still used SHARED_LDFLAGS, which seems
inconsistent.
To harmonize the two, any SHARED_CFLAGS gets renamed to LIB_CFLAGS and
SHARED_LDFLAGS to LIB_LDFLAGS. That makes the intent consistent along
with BIN_{C,LD}FLAGS and DSO_{C,LD}FLAGS.
Finally, make sure to pass down $(LIB_CFLAGS) or $(DSO_CFLAGS) along
with $(CFLAGS) when using Makefile.shared.
Reviewed-by: Rich Salz <rsalz@openssl.org>
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>
The reason for this is that the static libraries and the DLL import
libraries are named the same on Windows. When configured "shared",
the static libraries are unused anyway.
Reviewed-by: Rich Salz <rsalz@openssl.org>
This introduces the settings loutflag and aroutflag, because different
Windows tools that do the same thing have different ways to specify
the output file.
The Borland C++ config is commented away for the monent, perhaps
permanently.
Reviewed-by: Rich Salz <rsalz@openssl.org>
