Hi Tim, Well, the --enable-experimental switch was already added to Git master when I sent the e-mail. As for doing features in new branches, that is sometimes done, but in this case the specific goal was to expose the code to a broad range of build systems to see if there were any compile errors on some platforms -- intentionally long before putting the code near production, hence 'noinst' (and building it _last_, so even if it failed, the rest would just work). Still, I think the --enable-experimental flag is reasonable at this time.
Happy hacking! Christian On 10/23/2018 10:28 AM, Tim Rühsen wrote: > Hi Christian, > > sorry for answering so late :-( > > Such a switch would indeed be useful if one wants to test/use the latest > master branch. > > In my case it is using latest master as dependency for CI Testing of > Wget2. This includes a MinGW CI runner. > > Of course I can checkout the latest release tag, but atm I try to find > issues in MHD development early. > > There is also the possibility to slightly change the development cycle > of MHD: > - Add new a feature in an own branch > - Push that branch to Gitlab.com to test the code via CI (we already > created CI runners), optionally create an MR (merge request) for > discussion/collaboration. > - When CI succeeds: merging of the feature branch into master (directly > or via Gitlab UI) > > That way you keep the master branch clean and tested. > > Whatever you decide, let me know and I'll change my build scripts :-) > > Regards, Tim > > > On 10/18/18 5:34 PM, Christian Grothoff wrote: >> Hi Tim, >> >> The issue is that in line Makefile.am:10, we have "noinst_" instead of >> "lib_" because the code is far from complete and it must not yet be >> installed. That causes the dlname='' issue you describe. >> >> The best fix I can propose: I'm adding an option (--enable-experimental) >> which disables building src/lib/ by default, so that users that don't >> care about the experimental code don't get disrupted like this. >> >> Happy hacking! >> >> Christian >> >> On 10/18/2018 04:45 PM, Tim Rühsen wrote: >>> Hi, >>> >>> the build on MinGW fails in lib/src/ due to >>> >>> @echo Creating $@ and libmicrohttpd2.exp by $(DLLTOOL)... && \ >>> dll_name=`$(EGREP) -o dlname=\'.+\' libmicrohttpd2.la` && \ >>> >>> libmicrohttpd2.la contains >>> dlname='' >>> and thus the egrep (or grep -E) fails. >>> >>> I am on Debian unstable and use this sequence in a script: >>> >>> unset CC >>> PREFIX=x86_64-w64-mingw32 >>> export INSTALLDIR="$PWD/$PREFIX" >>> export PKG_CONFIG_PATH=$INSTALLDIR/lib/pkgconfig >>> export CPPFLAGS="-I$INSTALLDIR/include" >>> export LDFLAGS="-L$INSTALLDIR/lib" >>> export CFLAGS="-O2 -Wall -Wno-format" >>> >>> git clone --recursive https://github.com/dlfcn-win32/dlfcn-win32.git >>> cd dlfcn-win32 >>> ./configure --prefix=$PREFIX --cc=$PREFIX-gcc >>> make >>> cp -p libdl.a ../$PREFIX/lib/ >>> cp -p dlfcn.h ../$PREFIX/include/ >>> cd .. >>> >>> git clone --recursive https://gnunet.org/git/libmicrohttpd.git >>> cd libmicrohttpd >>> ./bootstrap >>> ./configure --build=x86_64-pc-linux-gnu --host=$PREFIX >>> --prefix=$INSTALLDIR --disable-doc --disable-examples --enable-shared >>> make clean >>> make -j$(nproc) >>> cd .. >>> >>> >>> Regards, Tim >>> >
0x939E6BE1E29FC3CC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
