From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9675 invoked by alias); 16 Sep 2009 00:44:02 -0000 Received: (qmail 9659 invoked by uid 22791); 16 Sep 2009 00:44:01 -0000 X-SWARE-Spam-Status: No, hits=-9.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_PASS X-Spam-Check-By: sourceware.org Received: from proofpoint2.lanl.gov (HELO proofpoint2.lanl.gov) (204.121.3.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 Sep 2009 00:43:57 +0000 Received: from mailrelay1.lanl.gov (mailrelay1.lanl.gov [128.165.4.101]) by proofpoint2.lanl.gov (8.14.3/8.14.3) with ESMTP id n8G0htGE000366 for ; Tue, 15 Sep 2009 18:43:55 -0600 Received: from alvie-mail.lanl.gov (alvie-mail.lanl.gov [128.165.4.110]) by mailrelay1.lanl.gov (Postfix) with ESMTP id A9CBC165126 for ; Tue, 15 Sep 2009 18:43:55 -0600 (MDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by alvie-mail.lanl.gov (Postfix) with ESMTP id A75D47D009D for ; Tue, 15 Sep 2009 18:43:55 -0600 (MDT) X-NIE-2-Virus-Scanner: amavisd-new at alvie-mail.lanl.gov Received: from [130.55.124.157] (manticore.lanl.gov [130.55.124.157]) by alvie-mail.lanl.gov (Postfix) with ESMTP id 97C977D009C for ; Tue, 15 Sep 2009 18:43:55 -0600 (MDT) Subject: Re: GSL 2.0 roadmap (one man's view) From: Gerard Jungman To: GSL Discuss Mailing List In-Reply-To: <87r5uoj68z.wl%bjg@network-theory.co.uk> References: <48E25CA9.6080306@iki.fi> <490DE4BD.7070907@iki.fi> <497B00F6.2080400@iki.fi> <498727E5.6080407@iki.fi> <49AA9DB5.6030908@iki.fi> <49FB01D1.30000@iki.fi> <4A7ADFDC.9080408@iki.fi> <1251414774.23092.80.camel@manticore.lanl.gov> <1251414939.23092.82.camel@manticore.lanl.gov> <87r5uoj68z.wl%bjg@network-theory.co.uk> Content-Type: text/plain Date: Wed, 16 Sep 2009 00:44:00 -0000 Message-Id: <1253061986.23092.953.camel@manticore.lanl.gov> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5,1.2.40,4.0.166 definitions=2009-09-15_11:2009-09-01,2009-09-15,2009-09-15 signatures=0 Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sourceware.org X-SW-Source: 2009-q3/txt/msg00043.txt.bz2 On Thu, 2009-09-03 at 19:19 +0200, Brian Gough wrote: > At Thu, 27 Aug 2009 17:15:39 -0600, > Gerard Jungman wrote: > > * Better overall organization, expression of module dependencies, etc. > > I would be happy to remove the goal of independent sublibraries from > the design document--it doesn't reflect reality. There are really several (partially) independent issues, all touched by the "Better organization" point. They relate to the build system, module dependencies, and the overall user experience. > I am not clear what benefit it would provide to users now anyway--is > there actually a problem with "one big library"? Yes, there is. As soon as GSL learns to talk with the rest of the world, dependency issues will arise. Sub-libraries should be insulated. Think of how something like a dependency on lapack might propagate through the system. There are related problems, related to dependencies and the nature of the build, which can be addressed by compartmentalizing the installation. This is helpful to package maintainers, whether they are preparing packages for a major distribution or they are local ad-hoc packagers, down to the level of one user. Simply put, the build and installation should be more modular. > If you want to avoid the symbolic linking of header files we could > just move them into the gsl/ directory instead of keeping them in the > individual subdirectories. (While the symlinks are ugly I don't think > they have ever actually caused a problem for anyone.) This is the upside down solution. The right way is simple; just change the includes to be hierarchical, so that client code would look like #include We talked about this 12 years ago, but we couldn't figure out how to get autotools to do this properly, for build and/or installation. Maybe somebody knows how. Maybe we should discard autotools. That should certainly be discussed. -- G. Jungman