Re: reference for beginner on configure/make/compile/linking/etc.

On Thursday 11 June 2009 14:09:43 Gary Gatten wrote:

It seems
COMPLETELY overly complex to me - maybe cause the developer tries to
make it as portable as possible, but with every *nix like things putting
files wherever they want, different cc's / ld's, etc. - I can see where
it can get hairy.

It *is* overly complex. The original design goal of "easily create portable
shell to configure and Makefiles" has long been replaced with "cruft now
requiring perl, additional files for linking (.la) and overall confusion when
things don't work". It is no wonder that larger projects are switching to
cmake and smaller to jam/scons.

That said, if the developers know what they're doing, you won't see any OS
assumption in the source code (#ifdef __FreeBSD__ and similar) and you would
be able to assert portability differences by grepping for
'^#ifn?def[[:space:]]+HAVE_' in headers and source. Problems with
configure/automake usually can be classified in the following categories:
- Unhandled cases developers are not aware of: prerequisite headers or headers
in different locations then are assumed. Library symbols in differently named
libraries.
- Attempt to figure out a prerequisite is present not directly supported by
autoconf/automake then created by the developers in not so portable script.
- Assumptions on struct members, number of arguments to certain functions,
size of data structures, presence of symbols.
- Lex/yacc/bison parser generator version problems.

I've always found curl (ftp/curl) port a good example of autoconf usage.
--
Mel
_______________________________________________
freebsd-questions@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: size_t problems
    ... Sometimes C developers need to choose between: ... Writing 100% portable code. ... Because C was one of the first languages I knew well, ... productivity AND portability through fixed size types. ...
    (comp.lang.c)
  • Re: size_t problems
    ... Writing 100% portable code. ... productivity is low compared to more pragmatic developers, ... Because C was one of the first languages I knew well, ... productivity AND portability through fixed size types. ...
    (comp.lang.c)
  • Re: which: command not found
    ... package, or as a member of the small & portable set of utilities used ... a tool-rich environment for use in the tool-rich environment. ... sympathize with DJGPP developers and embedded developers who may not ... volunteer willing to do the portability work. ...
    (comp.os.msdos.djgpp)
  • Re: Problem when defining my own string.h
    ... so this seems to be a known "idiom" among library ... developers.. ... don't recommend it (due to portability issues), but I think I can make ... You mean forward or backward slash? ...
    (microsoft.public.vc.language)