beaver-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Beaver-devel] About autotools and portability


From: Higor Eurípedes
Subject: Re: [Beaver-devel] About autotools and portability
Date: Sun, 28 Dec 2008 12:47:47 -0300

Erm, ok where to start?

> thanks for the work Higor. well I personally do not like the autotools at
> all. that has different reasons:

I do not like autotools too (at least not to configure them >.<). But
most systems doesnt have
autotools replacements like CMake or Cons or SCons.

> 1) the configure checks does a lot of checks which are completely useless
> and does not really help in ensuring that the build environment is correctly
> set up. for example it checks if "stdlib.h" and "string.h" is installed. but
> does not check for example for "stdio.h". and why check for these anyway.
> and i often had scripts that checked a lot, everything went fine and it
> didn't work after all.

Its possible to tell configure to check for stdio.h and also other headers.

> then on the other hand, really important things not get checked. for
> example: I've got a 64bit system and for that system the flag "-fPIC" has to
> be used otherwise beaver will not work properly. why does autotools does not
> get that? is this configurable? especially nowadays a lot of systems are
> 64bit so why not check it?

About the PIC flag it can be added manualy or we can use libtool
(comes with autotools)

> 2) it makes developping a lot harder. if there are warnings or errors, they
> are hard to find in all that stuff that get's scrolled. well it looks cool,
> but it doesn't really help me in developping. and where in the hell to I set
> the debug level? (well that probably is a bug of me :-) I think I'm just to
> stupid to find it, but then again, why hide it in those god awful
> configuration files?) and no: using "make install-strip" to remove the
> debugging level is just not the right way to do it, because all the
> optimizations are not done.

Its possible to configure the output to look like the older one (add a
custom .c.o target in src/Makefile.am and src/api/Makefile.am).
Its possible to add flags to the configure script that will create
Makefiles that compile the code with different debuglevels or no debug
symbol
Its possible to change the optimizations (-O2 is default if im not wrong)

> 3) the autotools compile a lot into the programs that were never used. why
> is the program 65kB bigger and has a 2MB bigger memory footprint? especially
> for our project where we want a small memory footprint this is not feasible.
> it's just not transparent enough. it does not really say what it does.

Huh 2mb bigger? i didnt notice it. Here on my machine it looks the
same, xcept for the executable size.

> a) I saw that you created a library out of the API.  Well this is not needed
> and it won't work with the actual code anyway (especially when you then link
> the plugins against this library, and if you don't then there's no sense in
> using a library anyway). The plugin system is designed to not need any
> shared library. The way you use it now is just to create an archive file and
> then compile it into the main program, which would be the same thing as just
> compiling it all in the first place.

The library is not instaled, its only used in the compilation process.
Plugins doesnt need the library.
Ive choosen autoconf 2.13 to work with, because most systems which
have autotools instaled have it, using the most
recent version i have in my machine (2.61) automake dont break when
compiling in subdirectories like src/api but it does
when you use 2.50 or 2.13, so i had to compile the api as a library
and link to the beaver executable.



 >
> The second thing is, that the Makefile (which get's called from the other
> Makefiles) is not that easy to maintain, but it should be.
>
> b) as I stated above, I do not like it, if it produces a lot of nonsense
> terminalscrolling text, which is useless in most of the time. I like how the
> kernel get's compiled and that's why I designed my Makefiles after that. Is
> this somehow possible to do with the autotools? To find warning and errors
> is really hard and makes my eyes hurt.
>
> c) the plugins Makefile and mkmakefile.sh does not work for me. Also I do
> not like if you have to use autotools to write some plugin. In my system you
> only had to copy paste the Makefile and everything worked. Here nothing
> worked for me? Or did I just used it wrong?
>
> I see, that if we want that beaver is portable we have to use some sort of
> configuration script. I had no problem in compiling beaver with my old
> machine (an ubuntu system) and with my new system (a gentoo system; okay on
> gentoo mostly everything works ^^). I would like to know what the problem
> was with freebsd? probably some paths were wrong?
>
> Again, I want to stress out, that this is not a criticism against you, but I
> just really hate autotools. If you could work the things out I stated above
> than I would be happy.
>
> Greets
> Tobias
>
>
> _______________________________________________
> Beaver-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/beaver-devel
>



-- 
Higor Euripedes (enygmata)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]