Can you please elaborate on what makes a non-header-only library so very Re: But it would Re: [gil] [announcement] New IO lib
Can you please elaborate on what makes a non-header-only library so very problematic?
Its probably more a UNIX thing, I'm not sure if windows developers could care one way or another. But on LINUX/UNIX, there is a central repository of pre-built libraries that we syncronize our builds against. Uncecessarily adding new libraries makes the process that much more to manage. It is "so" much easier to not have to bother with that and just have the compiler link in any functions that are used at compile time from the headers. You would be surprised to now how much compiler technology has improved in the last 3-4 years. The old reasons for making libraries are no longer always valid. Compilers are very smart and very fast, and thats how I pefer to code.
Tom Brinkman wrote:
Can you please elaborate on what makes a non-header-only library so very problematic?
Its probably more a UNIX thing, I'm not sure if windows developers could care one way or another. But on LINUX/UNIX, there is a central repository of pre-built libraries that we syncronize our builds against.
Why don't you rebuild your dependent libraries along with your code? Then you are guaranteed to have the right stuff. I mean, you already said you would like to recompile everything over and over with header-only stuff. Might as well make it official. -- Sohail Somani http://uint32t.blogspot.com
On Sat, Apr 26, 2008 at 3:51 PM, Tom Brinkman <reportbase@gmail.com> wrote:
Its probably more a UNIX thing, I'm not sure if windows developers could care one way or another.
For the record, I use Solaris 10, Linux (ubuntu Gutsy), and Windows w/ vc8. But on LINUX/UNIX, there is a central repository of pre-built
libraries that we syncronize our builds against.
Synchronize builds? Not sure exactly what you mean.
Uncecessarily adding new libraries makes the process that much more to manage.
Are you referring to the extra work it takes to build the boost libs for each supported os+compiler, and add them to your "repository" of 3rd party libraries?
Compilers are very smart and very fast, and thats how I pefer to code.
Compilers are indeed smart and fast. And it still takes a non-zero amount of time to compile the boost.FileSystem code. I still prefer to compile that once up front, and not tack that on to every successive build of my own code that I do. It takes a couple of hours to do a full rebuild of the code base that I work on. I prefer shaving anything off that I can. If a library is entirely inlined or template code, then it makes perfect sense to make the library header only. It also strikes me as silly to force a particular library to be something that its not. Jon
participants (3)
-
Jonathan Franklin -
Sohail Somani -
Tom Brinkman