If ZNC was already installed, it had its headers somewhere.
The chances are that something else can be installed at the same place,
including some ZNC's dependency whose include dir would be included to
CXXFLAGS. Another possibility of including that dir is triggered when
using FreeBSD - ./configure explicitly adds -I/usr/local/include in that
case.
And so we get a directory with old ZNC headers included to CXXFLAGS
before our new shiny ./include.
With their order changed, the proper headers are included now.
Thanks to those who repored the issue, thanks to PsWii60 for helping to
track it down, thanks to my parents for creating me and therefore
enabling me to fix it, and to many other people.
lahwran just showed up on irc and told us that he installed znc, but znc failed
to find any modules. The reason for this was his umask 077 which means that
"make install" installed stuff so that only root can access it.
The solution is do use "install -d" since that makes sure to ignore the
currently set umask.
However, google finds results which say that "install -d" might mess with stuff
of pre-existing directories when it shouldn't, so we must first test if the
directory already exists before calling install. Obviously, this makes our
Makefile a lot more readable. :-(
I didn't have time to test this properly, so stuff might break.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This will only ever be set to -DHAVE_CONFIG_H. However, we shouldn't give this
flag to other people's code (e.g. through znc-config). Since we don't need it,
it's best to just drop it completely.
Signed-off-by: Uli Schlachter <psychon@znc.in>
No module in extra/ comes with any data currently, so this was tested by moving
perform to extra/. The install is untested.
Signed-off-by: Uli Schlachter <psychon@znc.in>
python3-config fails when python is installed not system-wide.
It doesn't return -L/path/to/libs.
pkg-config resurns it.
Note that this changes meaning of optional argument to ./configure --enable-python=...
With cp -Rp, the files's permissions were just copied from source.
But 4c7808c5c broke that behaviour, so after copying we set permissions for new installed files.
Why "install" doesn't support installing directories? :(
If you did ./configure --enable-tcl, tcl wasn't actually enabled because
--enable-extra was missing, That's less than optimal.
Just moving modtcl out of modules/extra solves this problem.
Big thanks go to zynox/kylef for noticing this!
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit adds a zncconfig.h to ZNC that is automatically generated by
configure. This is done because the -DPACKAGE_STRING=\"znc\ 0.097\" that
configure adds to CXXFLAGS breaks znc-buildmod.
This means that we have to include zncconfig.h as the very first header in every
C++ file that is compiled. This commit kinda cheats and instead adds this
include as the very first thing to all header files we have. This should
hopefully mean that modules don't have to include this.
Because Csocket includes defines.h too late, this commit causes znc to divert
from upstream Csocket once again. :(
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@2250 726aef4b-f618-498e-8847-2d620e286838
On most systems, this should only result in some useless defines being added to
the compiler's command line:
-DPACKAGE_NAME=\"znc\" -DPACKAGE_TARNAME=\"znc\" -DPACKAGE_VERSION=\"0.097\"
-DPACKAGE_STRING=\"znc\ 0.097\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\"
However, on some weird arches like e.g. x86, this will make AC_SYS_LARGEFILE
actually work, because that macro adds "-D_FILE_OFFSET_BITS=64" to @DEPS@.
This was found by SilverLeo because modpython didn't compile for him, thanks. :)
(python has "#define _FILE_OFFSET_BITS 64" in pyconfig.h)
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@2242 726aef4b-f618-498e-8847-2d620e286838
This splits the modpython, modperl and modtcl specific parts of
modules/Makefile.in into separate files. There shouldn't be any other changes
than this in here (hopefully).
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@2209 726aef4b-f618-498e-8847-2d620e286838
- Make sure webskins are installed with the correct permissions even though we
don't use install for installing them.
- Make "make uninstall" use the correct path for webskins.
- Properly clean up the stuff generated by modperl and modpython on "make clean"
- Don't first install modperl/ and modpython/ only to remove them again later
- Use $(wildcard) to expand *.foo to the empty string if nothing matches.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@2201 726aef4b-f618-498e-8847-2d620e286838
Old modperl had several flaws and was very outdated.
New modperl makes the whole ZNC API accessible from inside perl.
Modperl API was changed, so old perl modules are not supported,
but they weren't used much anyway.
Modperl needs --enable-perl option to ./configure.
This introduces new dependence on SWIG, which is needed only while
compiling ZNC. So to use modperl, you need to install SWIG or
to download several files and use --disable-swig option of configure.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@2120 726aef4b-f618-498e-8847-2d620e286838
The real command line is now hidden and instead a short message which explains
what is done is displayed. To get back the old behavior, use "make VERBOSE=1".
Thanks to DarthGandalf for this.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@2094 726aef4b-f618-498e-8847-2d620e286838
$SHELL controls which shell is used for executing the commands in a Makefile.
Since modules/Makefile does not work with ksh, we need to find a "proper" shell.
Luckily, configure already did that job and announces its findings via @SHELL@.
This should make our Makefile work on Solaris.
Thanks to LeftWing aka Joshua M. Clulow.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@2064 726aef4b-f618-498e-8847-2d620e286838
That directory was removed in r1997 so trying to install it might be rather
tricky (in fact, it failed and caused 'make install' to abort).
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@2000 726aef4b-f618-498e-8847-2d620e286838
