Hi all, Wow. I guess I'm glad I didn't check my email until lunch at work today. FWIW, I use both projects at home. I skimmed the other thread, and my reply will be brief.
Getting compatible CFLAGS and LDFLAGS is a hard problem, and it comes up regularly. A few approaches are common in this situation (numbered at random): 1) The library (ECL) provides a tool like pkg-config to retrieve flags. 2) The program (OpenAxiom) directly configures and compiles the library. 3) The program guesses flags based on known tokens (e.g. uname or *features*) (FRAGILE!! see imake) 4) The program compiles and links test programs to see what works (e.g. autoconf) I have a preference for (4); at the end of the day, it is both flexible and reliable. However, it is often the most difficult to implement (especially on MS-broken-windows). As a middle ground, I often start implementing (4) as a simple wrapper for the other methods, extending it when problems are found. Option (1) looks easy, and it can be required for some things. (See Autoconf notes on things that can't be detected automatically, or see the recent Libtool thread on detecting /usr/local/lib vs /usr/local/lib64.) However, (1) fails when the program needs information not anticipated by the library. It also involves redundant information (a common source of inconsistency). Option (2) works nicely when you don't have to reuse system libraries. End users often think it is easy (since the program can include the library in a single downloadable). I sometimes wish *features* had been deprecated. It can lead to a kludgey coding style, is easily implemented in user space, and I've wanted to use those macro characters a few times. Implementations are often cavalier about what they put on there, and code often infers much more than it should. Classic example: checking #+(or lisp-a lisp-b) to see if a function is available, rather than directly checking for the function... When the library maintainers are willing to work with the program developers, it can often work to move the data from (4) into a format accessible via (1). Thus on autoconf platforms, CC, CFLAGS, etc. are passed straight through; where the library uses other build systems (e.g. wince), hard-coded settings are maintained with the build configuration. That was less brief than I intended... Later, Daniel ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list