Skip to content

Commit

Permalink
Don't delete SRCDIR/zconf.h when building out of tree
Browse files Browse the repository at this point in the history
This avoids dirtying the source directory when building out of tree

Various build changes to make sure this works:
 - Includes for arch dir specify BUILDDIR before SRCDIR
 - #include <zconf.h> instead of "zconf.h": that way the include order
   takes effect.
 - Insert an #error directive in the original zconf.h that we process out.
   That way we can be sure we are including the right one when building
   out of tree.

Signed-off-by: Daniel Axtens <[email protected]>
  • Loading branch information
daxtens committed May 5, 2015
1 parent 8142dbf commit ff7c02c
Show file tree
Hide file tree
Showing 5 changed files with 12 additions and 5 deletions.
9 changes: 5 additions & 4 deletions configure
Original file line number Diff line number Diff line change
Expand Up @@ -421,9 +421,6 @@ else
echo "Checking for strerror... No." | tee -a configure.log
fi

# We need to remove zconf.h from source directory if building outside of it
if [ "$SRCDIR" != "$BUILDDIR" ]; then rm -f $SRCDIR/zconf.h; fi

This comment has been minimized.

Copy link
@mtl1979

mtl1979 May 6, 2015

Collaborator

$SRCDIR/zconf.h is deleted anyways when using cmake, so removing these lines is counter-productive... It adds one unnecessary warning. The correct solution would be to fix Windows build system to use zconf.h.in to generate temporary copy of zconf.h and remove zconf.h and various other generated files from git repository.

This comment has been minimized.

Copy link
@daxtens

daxtens May 7, 2015

Author Contributor

We should fix the cmake setup then. Deleting zconf.h dirties the source tree.

This comment has been minimized.

Copy link
@mtl1979

mtl1979 May 7, 2015

Collaborator

Deleting zconf.h is part of bigger change in how the source tree is built... We have to do the cleanup bit by bit so we can be sure it works with both nmake and GNU make, and both with running configure and without running it but using cmake instead. If someone just unzip newer copy of the source tree over old copy, we must detect this as in no case we should require user always has git available. A lot of things in the build system is necessary redundancy to keep files of different build styles in sync.


# copy clean zconf.h for subsequent edits
cp -p $SRCDIR/zconf.h.in zconf.h

Expand Down Expand Up @@ -465,6 +462,10 @@ if test $zprefix -eq 1; then
echo "Using z_ prefix on all symbols." | tee -a configure.log
fi

# take out the error path that makes sure an out of tree build doesn't touch the source tree's zconf.h
sed < zconf.h 's/#error.*//' > zconf.temp.h
mv zconf.temp.h zconf.h

# if --solo compilation was requested, save that in zconf.h and remove gz stuff from object lists
if test $solo -eq 1; then
sed '/#define ZCONF_H/a\
Expand Down Expand Up @@ -742,7 +743,7 @@ sed < $SRCDIR/Makefile.in "
mkdir -p $ARCHDIR

ARCHINCLUDES="-I$SRCDIR/$ARCHDIR -I$SRCDIR"
if [ "$SRCDIR" != "$BUILDDIR" ]; then ARCHINCLUDES="${ARCHINCLUDES} -I$BUILDDIR"; fi
if [ "$SRCDIR" != "$BUILDDIR" ]; then ARCHINCLUDES="-I$BUILDDIR ${ARCHINCLUDES}"; fi

sed < $SRCDIR/$ARCHDIR/Makefile.in "
/^CC *=/s#=.*#=$CC#
Expand Down
2 changes: 2 additions & 0 deletions zconf.h
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,8 @@

/* @(#) $Id$ */

#error "Error: unprepared zconf.h included. Build system broken."

This comment has been minimized.

Copy link
@mtl1979

mtl1979 May 6, 2015

Collaborator

This definitely breaks building under Windows as it doesn't use configure.

#ifndef ZCONF_H
#define ZCONF_H

Expand Down
2 changes: 2 additions & 0 deletions zconf.h.cmakein
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,8 @@

/* @(#) $Id$ */

#error "Error: unprepared zconf.h included. Build system broken."

This comment has been minimized.

Copy link
@mtl1979

mtl1979 May 6, 2015

Collaborator

There is nothing added to CMakeLists.txt to handle this... It is by definition optional to run configure before cmake. This change breaks the build.


#ifndef ZCONF_H
#define ZCONF_H
#cmakedefine Z_PREFIX
Expand Down
2 changes: 2 additions & 0 deletions zconf.h.in
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,8 @@

/* @(#) $Id$ */

#error "Error: unprepared zconf.h included. Build system broken."

#ifndef ZCONF_H
#define ZCONF_H

Expand Down
2 changes: 1 addition & 1 deletion zlib.h
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,7 @@
#ifndef ZLIB_H
#define ZLIB_H

#include "zconf.h"
#include <zconf.h>

#ifdef __cplusplus
extern "C" {
Expand Down

12 comments on commit ff7c02c

@daxtens
Copy link
Contributor Author

@daxtens daxtens commented on ff7c02c May 7, 2015

Choose a reason for hiding this comment

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

Yeah, I haven't been considering Windows or CMake. If we're going to go the Cmake route we should go the whole way and drop ./configure completely.

In other news I think this breaks things subtly and should be reverted for now until I can fix it a bit better. (Relatedly, we should probably enable Travis on this repo --- all the bits are there!)

@daxtens
Copy link
Contributor Author

@daxtens daxtens commented on ff7c02c May 7, 2015

Choose a reason for hiding this comment

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

More broadly, we could drop prefix support and clean up the data types and then simply drop zconf.h. That might be vastly better.

@Dead2
Copy link
Member

@Dead2 Dead2 commented on ff7c02c May 7, 2015

Choose a reason for hiding this comment

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

Dropping prefix support is indeed something I have been considering.

@mtl1979
Copy link
Collaborator

@mtl1979 mtl1979 commented on ff7c02c May 7, 2015

Choose a reason for hiding this comment

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

I will try to adjust Visual C++ makefile so it can gracefully handle if zconf.h is missing... Currently it still depends on zconf.h.in. I will make pull requests when I finish each part of the cleanup as long as the patch doesn't introduce merge conflict with the current state of the upstream source tree. This pretty much requires me to keep HEAD of my private clone few revisions behind the public one and cherry-picking changes from upstream that don't conflict to separate temporary branches.

@daxtens
Copy link
Contributor Author

@daxtens daxtens commented on ff7c02c May 7, 2015

Choose a reason for hiding this comment

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

It's very difficult for me to test this because I don't have access to a Visual C++ environment. Will burninating zconf.h entirely make this easier? I was going to work on that shortly.

@mtl1979
Copy link
Collaborator

@mtl1979 mtl1979 commented on ff7c02c May 8, 2015

Choose a reason for hiding this comment

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

If we drop zconf.h from git repository, win32/Makefile.msc will recreate it automatically... It won't break as long as nothing in zconf.h.in depends on configure.
zconf.h.cmakein is something that has to be dealt in completely different way... I need to read the cmake manuals if there is clean way to automatically create it from zconf.h.in like configure does...

@daxtens
Copy link
Contributor Author

@daxtens daxtens commented on ff7c02c May 8, 2015

Choose a reason for hiding this comment

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

I was thinking of getting rid of zconf.h, zconf.h.in, and zconf.h.cmakein. I'm doing a bunch of cleanups along that line, I'll see how far I get.

@daxtens
Copy link
Contributor Author

@daxtens daxtens commented on ff7c02c May 8, 2015

Choose a reason for hiding this comment

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

@mtl1979: If you're online, do you know if recent versions of windows support vnsprintf? It's in gzguts.h.

Maybe we should get an IRC channel?

@mtl1979
Copy link
Collaborator

@mtl1979 mtl1979 commented on ff7c02c May 8, 2015

Choose a reason for hiding this comment

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

@daxtens As far as I know, Visual C++ does have vsnprintf()

@Dead2
Copy link
Member

@Dead2 Dead2 commented on ff7c02c May 8, 2015

Choose a reason for hiding this comment

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

@daxtens @mtl1979 #zlib-ng at freenode

@mtl1979
Copy link
Collaborator

@mtl1979 mtl1979 commented on ff7c02c May 8, 2015

Choose a reason for hiding this comment

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

zconf.h and zconf.h.cmakein are gone now... Both are automatically generated on all targets I could test (cmake+linux, configure+linux, Visual C++/nmake)

@mtl1979
Copy link
Collaborator

@mtl1979 mtl1979 commented on ff7c02c May 8, 2015

Choose a reason for hiding this comment

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

@Dead2 Fine with me... Just had to install IRC client ;)

Please sign in to comment.