On Mon, Mar 26, 2012 at 8:02 PM, Alon Bar-Lev <alon.bar...@gmail.com> wrote: > On Mon, Mar 26, 2012 at 7:55 PM, Gert Doering <g...@greenie.muc.de> wrote: >> Hi, >> >> On Mon, Mar 26, 2012 at 07:51:01PM +0200, Alon Bar-Lev wrote: >>> The benefit is to divide the code into libraries and core which is >>> easier to maintain and reuse. >> >> I'm not sure I understand what's so hard about "compile stuff, use >> 'ar' to pack into libopenvpn.a" that stuff needs more convolutions. >> >> We're not building a shared library - which I agree is major pains unless >> handled by libtool. But static libraries are easy on about everything >> (except Windows, can't speak about that). > > libtool has the advantage of making it very simple as far as build is > maintenance is, in all platforms in exact same way. > It also will enable us to build the plugins properly in future. > Even if you do what you suggested (ar), the gcc command-line will be > long as we need to add the additional CPPFLAGS, LDFLAGS.
The --- ".deps/status.Tpo" -c -o status.o status.c; then mv -f ".deps/status.Tpo" ".deps/status.Po"; else rm -f ".deps/status.Tpo" --- Are for dependency tracking, so that if you change a file dependencies will be recompiled... This was the same in previous build. So we had: --- gcc -DHAVE_CONFIG_H -I. -I. -I/usr/kerberos/include -g -O2 -MT status.o -MD -MP -MF .deps/status.Tpo -c -o status.o status.c --- And now: --- if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -I../../src/compat -I/usr/include -I/usr/include -g -O2 -MT status.o -MD -MP -MF ".deps/status.Tpo" -c -o status.o status.c; then mv -f ".deps/status.Tpo" ".deps/status.Po"; else rm -f ".deps/status.Tpo"; exit 1; fi --- What this makes sure is that if compile fails the dependencies is removed.... Delta: --- if (.*); then mv -f ".deps/status.Tpo" ".deps/status.Po"; else rm -f ".deps/status.Tpo"; exit 1; fi --- Not worth dropping the comfort of libtool and manually code toolchain commands just to remove this delta. >>> Anyway, new automake does support silent rules, try the following[1] >>> patch and see if it makes you happier. >> >> This is missing the point: I think what automake/autoconf is doing now >> is much too complicated. I *like* to see what it's doing, and hiding >> complexity by just not showing it is a step into the wrong direction. > > When you like, use "make V=1", or --disable-silent-rules to configure. > >> >>> Again, this demonstrate how current merge procedure is inappropriate, >>> as instead of single build system rewrite merge we have aftershocks. >>> Branch should be tested and reviewed, and tested and reviewed until >>> no known issues found, and all happy of its quality. >> >> We're doing that now: branch is called "master". > > Nope, this is not the rule of "master" branch. > "master" = as much stable as possible, not playground. > > Alon.
