Skip to content

Conversation

@levitte
Copy link
Member

@levitte levitte commented Feb 26, 2020

This started with a bug notification I got, that apps/progs.pl would fail at times. It turns out that it should be run from the build tree, not from the source tree.

This also touched an older thought, that some files (the majority of them) that we currently generate with make update and thereby have versioned don't actually need it. They can as well be generated in build time.

This PR changes things so apps/progs.c and apps/progs.h are generated at build time, and adds the necessary expansions of the build.info syntax to allow this to be done smoothly enough.

@levitte levitte added branch: master Applies to master branch approval: review pending This pull request needs review by a committer labels Feb 26, 2020
@levitte levitte added this to the 3.0.0 milestone Feb 26, 2020
@levitte
Copy link
Member Author

levitte commented Feb 26, 2020

@romen, would you mind trying this with your setup?

@romen
Copy link
Member

romen commented Feb 26, 2020

I am not capable of reviewing the Perl, but I can give feedback on testing.

Setup

mkdir -p $HOME/test_oot/b/build
cd $HOME/test_oot
git clone $OPENSSL_GIT_URL # plus some setup to have refs for github PRs
cd openssl
git co github/pr-11185
S=`pwd`
cd $HOME/test_oot/b/build
$S/config
make update
make [-j8] build_generated # I am avoiding the parallel make run at the moment for debugging
make [-j8] build_all_generated # I am avoiding the parallel make run at the moment for debugging
make doc-nits
make [-s -j8] # I am avoiding the parallel make run at the moment for debugging
make cmd-nits
make VF=1 test

Results

  1. $SRC/config works
  2. make update does not fail anymore with this change
  3. make build_generated does not fail
  4. make build_all_generated does not fail
  5. make doc-nits does not fail
  6. make fails with
ar: creating apps/libapps.a
ar: creating libcrypto.a
ar: creating libssl.a
ar: creating providers/libcommon.a
ar: creating providers/libfips.a
ar: creating providers/libimplementations.a
ar: creating providers/liblegacy.a
ar: creating providers/libnonfips.a
ar: creating test/libtestutil.a
../../openssl/apps/dhparam.c:23:11: fatal error: progs.h: No such file or directory
 # include "progs.h"
           ^~~~~~~~~
compilation terminated.
Makefile:21484: recipe for target 'apps/openssl-bin-dhparam.o' failed
make[1]: *** [apps/openssl-bin-dhparam.o] Error 1
Makefile:2873: recipe for target 'build_sw' failed
make: *** [build_sw] Error 2

@levitte
Copy link
Member Author

levitte commented Feb 26, 2020

Found the problem, fixup commit added

@romen
Copy link
Member

romen commented Feb 26, 2020

With the latest fixup commit I can confirm I don't get failures in my setup, but Travis failures seem relevant!

@richsalz
Copy link
Contributor

don't you need to put the removed files into .gitignore?

@romen
Copy link
Member

romen commented Feb 26, 2020

@levitte I also noticed a

grep: ./util/../include/openssl/opensslv.h: No such file or directory

message that seems to be triggered by $ if [ -n "$DESTDIR" ]; then sh .travis-create-release.sh $TRAVIS_OS_NAME; tar -xzf _srcdist.tar.gz; mkdir _build; cd _build; srcdir=../_srcdist; top=..; else srcdir=.; top=.; fi

it does not cause a failure, but maybe it is worth investigating?

@t8m
Copy link
Member

t8m commented Feb 26, 2020

You could drop the NOUPDATE variable support from .travis.yml that I've added in #11181 to workaround the progs update with no-deprecated.

@levitte
Copy link
Member Author

levitte commented Feb 26, 2020

grep: ./util/../include/openssl/opensslv.h: No such file or directory

Is this new? Surprising, that should have happened long ago. util/mktar.sh in master needs a bit of adaptation, it should read the VERSION file. I'll get to that tomorrow

@romen
Copy link
Member

romen commented Feb 26, 2020

grep: ./util/../include/openssl/opensslv.h: No such file or directory

Is this new? Surprising, that should have happened long ago. util/mktar.sh in master needs a bit of adaptation, it should read the VERSION file. I'll get to that tomorrow

There is a high probability that this has been there for a long time now, but we don't notice because it does not trigger an error and is hidden in the travis output!

@levitte
Copy link
Member Author

levitte commented Feb 27, 2020

util/mktar.sh fixed in #11190. The error doesn't impact Travis because we give the tarball and content prefix a name that's not derived on the version, so it's not relevant here.

@levitte levitte force-pushed the build.info-fixups-20200226 branch from edb2cd4 to 7346d94 Compare February 27, 2020 01:09
@levitte
Copy link
Member Author

levitte commented Feb 27, 2020

You could drop the NOUPDATE variable support from .travis.yml that I've added in #11181 to workaround the progs update with no-deprecated.

Done.

@romen
Copy link
Member

romen commented Feb 27, 2020

Still failing in Travis with

$ if ! $make2; then echo -e '\052\052 FAILED -- MAKE'; travis_terminate 1; fi;
ar: creating apps/libapps.a
ar: creating libcrypto.a
ar: creating libssl.a
ar: creating providers/libcommon.a
ar: creating providers/libfips.a
ar: creating providers/libimplementations.a
ar: creating providers/liblegacy.a
ar: creating providers/libnonfips.a
ar: creating test/libtestutil.a
Couldn't open apps/progs.c: No such file or directory
Makefile:21421: recipe for target 'apps/progs.h' failed
make[1]: *** [apps/progs.h] Error 2
Makefile:2862: recipe for target 'build_sw' failed
make: *** [build_sw] Error 2
** FAILED -- MAKE

@levitte
Copy link
Member Author

levitte commented Feb 27, 2020

Aha, apps/progs.c must be made before apps/progs.h... of course.
Fixed!

Copy link
Member

@t8m t8m left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The openssl build system is becoming so full-featured that it could be eventually shipped as a separate product. 😄

@levitte
Copy link
Member Author

levitte commented Feb 27, 2020

The openssl build system is becoming so full-featured that it could be eventually shipped as a separate product. 😄

Hush, don't give my secret plans away 😉

@romen
Copy link
Member

romen commented Feb 27, 2020

The openssl build system is becoming so full-featured that it could be eventually shipped as a separate product. smile

Hush, don't give my secret plans away

EVP_Build?

@romen
Copy link
Member

romen commented Feb 27, 2020

I just manually restarted the failing (timeout) travis job

@richsalz
Copy link
Contributor

I know there are smiley faces here, but I think the project should be concerned about the amount of Perl knowledge necessary to change things. When Andy left it took a very long time to partially recover perlasm knowledge.

@levitte
Copy link
Member Author

levitte commented Feb 28, 2020

All CIs are go

Copy link
Member

@t8m t8m left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving although it would be nice to have another review of the perl changes by someone with more perl skills.

@t8m t8m added approval: done This pull request has the required number of approvals and removed approval: review pending This pull request needs review by a committer labels Feb 28, 2020
@openssl-machine openssl-machine removed the approval: done This pull request has the required number of approvals label Feb 29, 2020
@openssl-machine
Copy link
Collaborator

This pull request is ready to merge

@openssl-machine openssl-machine added the approval: ready to merge The 24 hour grace period has passed, ready to merge label Feb 29, 2020
levitte added 6 commits March 2, 2020 03:34
So far, the "index" part of KEYWORD[whatever] could only handle one
item.  There are cases, however, where we want to add the exact same
value to multiple items.  This is especially helpful if a variable
that may have multi-item values are used in the "index" part.

Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from openssl#11185)
Use case: having a variable with multiple source files in its value,
and wanting to refer to the corresponding object file.

    $SRCS=foo.c bar.c
    SOURCE[program]=$SRCS
    DEPEND[${SRCS/.c/.o}]=prog.h

    GENERATE[prog.h]=...

Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from openssl#11185)
util/progs.pl depends on the build tree (on configdata.pm,
specifically), so it needs to be run from the build tree.  But why
stop there?  We might as well generate apps/progs.c and apps/progs.h
when building.

Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from openssl#11185)
There were some remaining old code and comments that don't serve a
purpose any longer.

Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from openssl#11185)
Since they are generated in build time, there's not need to keep them
in the source tree.

Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from openssl#11185)
It was a temporary measure to deal with the fact that util/progs.pl
didn't work right at all times, but that has now been fixed.

Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from openssl#11185)
@levitte levitte force-pushed the build.info-fixups-20200226 branch from b3f8f67 to 97ace6c Compare March 2, 2020 02:36
@openssl-machine openssl-machine merged commit 97ace6c into openssl:master Mar 2, 2020
@levitte levitte deleted the build.info-fixups-20200226 branch March 2, 2020 02:37
romen added a commit to romen/openssl that referenced this pull request Jun 12, 2020
Change relative nesting depth of the OOT build_dir

Build failures seem to depend on what is the relative nesting level
between $srcdir and $blddir. This seems potentially related to:

- openssl#11184
- openssl#11185
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approval: ready to merge The 24 hour grace period has passed, ready to merge branch: master Applies to master branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants