- 10 3月, 2016 1 次提交
-
-
由 Richard Levitte 提交于
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: NRich Salz <rsalz@openssl.org>
-
- 09 3月, 2016 2 次提交
-
-
由 Richard Levitte 提交于
This change is a bit more complex, as it involves several recipe variants. Also, remove the $(CROSS_COMPILE) prefix for the makedepend program. When we use the program "makedepend", this doesn't serve anything, and when we use the compiler, this value isn't even used. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
For assembler, we want the final target to be foo.s (lowercase s). However, the build.info may have lines like this (note upper case S): GENERATE[foo.S]=foo.pl This indicates that foo.s (lowercase s) is still to be produced, but that producing it will take an extra step via $(CC) -E. Therefore, the following variants (simplified for display) can be generated: GENERATE[foo.S]=foo.pl => foo.s: foo.pl $(PERL) $foo.pl $@.S; \ $(CC) $(CFLAGS) -E -P $@.S > $@ && \ rm -f $@.S GENERATE[foo.s]=foo.pl => foo.s: foo.pl $(PERL) $foo.pl $@ GENERATE[foo.S]=foo.m4 => foo.s: foo.m4 m4 -B 8192 $foo.m4 > $@.S; \ $(CC) $(CFLAGS) -E -P $@.S > $@ && \ rm -f $@.S GENERATE[foo.s]=foo.m4 => foo.s: foo.m4 m4 -B 8192 $foo.m4 > $@ Reviewed-by: NAndy Polyakov <appro@openssl.org>
-
- 08 3月, 2016 2 次提交
-
-
由 Richard Levitte 提交于
For config targets such as 'dist', which doesn't have a BASE template, we still need to have a default build scheme. Additionally, the unified Makefile template's target 'tar' wasn't quite as flexible as the unixmake one. Finally, .travis-create-release.sh can be somewhat simplified now that it builds with the unified build scheme. Reviewed-by: NMatt Caswell <matt@openssl.org>
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 04 3月, 2016 2 次提交
-
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
This construct in a Makefile is a bit overzealous: @echo FOO @FOO Cleaned up. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 03 3月, 2016 2 次提交
-
-
由 Richard Levitte 提交于
We copied $target{cflags}, $target{defines} and a few more to %config, just to add to the entries. Avoid doing so, and let the build templates deal with combining the two. There are a few cases where we still fiddle with %target, but that's acceptable. Reviewed-by: NAndy Polyakov <appro@openssl.org>
-
由 Richard Levitte 提交于
$target{lflags} and $target{plib_flag} were copied to %config for no good reason. Reviewed-by: NAndy Polyakov <appro@openssl.org>
-
- 01 3月, 2016 1 次提交
-
-
由 Richard Levitte 提交于
Reviewed-by: NAndy Polyakov <appro@openssl.org>
-
- 28 2月, 2016 2 次提交
-
-
由 Richard Levitte 提交于
When building with GNU C, clang or VMS C, it's more efficient to generate dependency file and object file in one call rather than two. Have the dependency output in a temporary file and compare it with the previous one if available to see if replacement is waranted, thereby avoiding unnecessary reconstruction of Makefile / descrip.mms. Github issue #750 Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Rich Salz 提交于
I read the PROBLEMS, and they're outdated; nothing I'd put in the online FAQ, for example. Test-builds work without using these files. Had to remove the rehash.time stuff from Makefile.in Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
- 27 2月, 2016 1 次提交
-
-
由 Rob Percival 提交于
Reviewed-by: NBen Laurie <ben@openssl.org> Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 25 2月, 2016 1 次提交
-
-
由 Richard Levitte 提交于
If the local system doesn't have GNU C or clang, and not even makedepend, the build will stop because the call of 'makedepend' fails. This changes so the build won't stop because of such failure. The result will be empty .d files, and that's ok. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 22 2月, 2016 1 次提交
-
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 21 2月, 2016 4 次提交
-
-
由 Richard Levitte 提交于
On slower file systems, this makes a huge difference Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
GNU make will re-exec if (it thinks that) the Makefile has changed. Just having the target Makefile seems to make it think it has, so we end up in a look where GNU make re-execs for ever. The fix is easy, just remove the Makefile target and have the depend target run the recipe on its own instead of depending on Makefile. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Ben Laurie 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
由 Ben Laurie 提交于
is a .s). Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
- 20 2月, 2016 3 次提交
-
-
由 Richard Levitte 提交于
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: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
It failed to remove lingering Makefile.new Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
It was turning off output again in two place where it should have turned it on. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 19 2月, 2016 16 次提交
-
-
由 Richard Levitte 提交于
Reviewed-by: NAndy Polyakov <appro@openssl.org>
-
由 Richard Levitte 提交于
Better libclean that removes the exact files that have been built, nothing more and nothing less. Corrected typo A couple of editorial changes. Reviewed-by: NAndy Polyakov <appro@openssl.org>
-
由 Richard Levitte 提交于
Of course, if there are remaining files in a directory, it won't be removed. Reviewed-by: NAndy Polyakov <appro@openssl.org>
-
由 Richard Levitte 提交于
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: NAndy Polyakov <appro@openssl.org>
-
由 Richard Levitte 提交于
Instead of having the installation recipe rely on special knowledge, feed it with information, including what shared library files belong together. For Cygwin and Mingw, that's the .dll and its import library .dll.a. For Unixen, it's the shared library file name with SO version and the one without. Reviewed-by: NAndy Polyakov <appro@openssl.org>
-
由 Richard Levitte 提交于
Originally, the Makefile.shared targets described what they used as input for a shared object, be it a shared library or a DSO. It turned out, however, that the link_o targets were used exclusively for engines and the link_a targets were for libcrypto and libssl. This rename fest turns and indication on the kind of input the targets get to the intention with using them. Reviewed-by: NAndy Polyakov <appro@openssl.org>
-
由 Richard Levitte 提交于
Reviewed-by: NAndy Polyakov <appro@openssl.org>
-
由 Richard Levitte 提交于
Then it can pass around the information where it belongs. The Makefile templates pick it up along with other target data, the DSO module gets to pick up the information through crypto/include/internal/dso_conf.h Reviewed-by: NAndy Polyakov <appro@openssl.org>
-
由 Richard Levitte 提交于
This is done with a simple file name comparison. We could think of something more elegant in the future. Reviewed-by: NAndy Polyakov <appro@openssl.org>
-
由 Richard Levitte 提交于
Some directories weren't removed. Reviewed-by: NAndy Polyakov <appro@openssl.org>
-
由 Richard Levitte 提交于
The benefit with using configdata.pm is that Configure writes it for us. Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
-
由 Richard Levitte 提交于
This isn't the fully featured combination of compiler generated dependency files and Makefile include directives, but a cheaper variant of the same. The dependency files are generated automatically, but then we have the usual "depend" target. However, we depend on it in the bigger phony targets that are the most likely to be used. That make this feature automatic enough. A side effect is that we can't use the build file's timestamp to check if reconfiguring might be in order. In its place, we use a flag file that depends on Configure and the build file template and depend on it in spots where it makes sense to check for the need to reconfigure. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
When cross compiling, we may end up with someting like apps/openssl.exe and a number of test/*.exe. However, util/shlib_wrap.sh doesn't know what the executable extension should be, if any, so we need to make sure it has access to that information when testing, since OpenSSL::Test uses that script to execute all programs. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
All those flags existed because we had all the dependencies versioned in the repository, and wanted to have it be consistent, no matter what the local configuration was. Now that the dependencies are gone from the versioned Makefile.ins, it makes much more sense to use the exact same flags as when compiling the object files. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
.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: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 15 2月, 2016 2 次提交
-
-
由 Richard Levitte 提交于
That variable isn't for us, it's for any user, distributor or package builder that wants one after the section number. "ssl" seems to be popular... Reviewed-by: NMatt Caswell <matt@openssl.org>
-
由 Ben Laurie 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org>
-