Re: CFO: Why ./configure?
From: Thomas Richter (thor_at_cleopatra.math.tu-berlin.de)
Date: 09/12/03
- Next message: Matt: "gdb in redhat 8.0"
- Previous message: Thomas Richter: "Re: CFO: Why ./configure?"
- In reply to: wereHamster: "Re: CFO: Why ./configure?"
- Next in thread: wereHamster: "Re: CFO: Why ./configure?"
- Reply: wereHamster: "Re: CFO: Why ./configure?"
- Reply: VBDis: "Re: CFO: Why ./configure?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 12 Sep 2003 13:14:21 GMT
Hi,
>> "autoconf" can handle more cases than you could handle manually. There
>> are many things to be concerned about, and some people already knew about.
>> Thus, even though I might know that on some IRIX versions I must include
>> <bstring.h> to get a memcpy, others might not. That's a kind of idea
>> autoconf can handle for you: It "imports knowledge" of the build process
>> into your own tools. Let others help you here with their knowledge.
>> Thus, whereas autoconf surely introduces more possible errors - nobody
>> is perfect - it can handle more problem cases than you could by hand.
> wouldn't it be easier to create a header memory.h ( as a symlink or a
> copy of bstring.h ) to gain the compatibility?
No, I'm not the administrator of the system. I can't do that. Instead,
I put a "string.h" into my sources that includes "config.h" which was
generated by configure from "config.h.in". "string.h" checks by testing
for the defines in config.h whether I need to include bstring.h or not.
> centralized means for me: one makefile, no recursion of makefiles, no
> helper tools (automake), just 'make' is enough.
> i think this makefile should work on all unix/linux platforms:
> cc = icc (or gcc)
> cflags = -g -O1
> libs = -L./libs -ldl
> ${cc} ${cflags} -c -o ./object.o ./src/file.c
> ${cc} -shared -o ./libfoo.so ${libs} ./obbject.o
> so why autotools?
Because that makefile doesn't work here. Where's the X11 include I need?
Where's the ncurses include I need? How or why does this call trigger
makes in all the sub-directories? Where's the documentation created?
Where's the archive packed?
You can also call the compiler by hand, but why?
>> Except that they won't be able to. What burden do you want to put onto the
>> shoulders of your users? Edit the makefiles? Ok, fine. Being sarcastic, I
>> could also say that the users could equally well write the program
>> themselves. (-;
> i think it's not harder to edit a makefile as to run "./configure
> --prefix=/home/tom/root"
It seems you haven't seen complex software projects yet. The makefiles
here do more than just to build programs, and they do more than just to
put a single executable into a specific disk location. They're not so easy
to follow, and not five-liners.
So long,
Thomas
- Next message: Matt: "gdb in redhat 8.0"
- Previous message: Thomas Richter: "Re: CFO: Why ./configure?"
- In reply to: wereHamster: "Re: CFO: Why ./configure?"
- Next in thread: wereHamster: "Re: CFO: Why ./configure?"
- Reply: wereHamster: "Re: CFO: Why ./configure?"
- Reply: VBDis: "Re: CFO: Why ./configure?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|