Hi Christian, tested --enable-experimental but then - guess what :-) - I need to 'make install' which fails. So I'm back at checking out the latest release tag. NP, I am just going to wait until the next release.
Regards, Tim On 10/23/18 12:53 PM, Christian Grothoff wrote: > 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 >>>> >>
signature.asc
Description: OpenPGP digital signature
