Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #136342 > unrolled thread
| Started by | Bart <bc@freeuk.com> |
|---|---|
| First post | 2018-10-06 15:13 +0100 |
| Last post | 2018-10-11 23:18 -0700 |
| Articles | 20 on this page of 147 — 22 participants |
Back to article view | Back to comp.lang.c
software disenchantment Bart <bc@freeuk.com> - 2018-10-06 15:13 +0100
Re: software disenchantment David Kleinecke <dkleinecke@gmail.com> - 2018-10-06 09:54 -0700
Re: software disenchantment Thiago Adams <thiago.adams@gmail.com> - 2018-10-06 10:26 -0700
Re: software disenchantment fir <profesor.fir@gmail.com> - 2018-10-14 04:26 -0700
Re: software disenchantment antispam@math.uni.wroc.pl - 2018-10-09 18:20 +0000
Re: software disenchantment David Kleinecke <dkleinecke@gmail.com> - 2018-10-09 11:54 -0700
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-09 21:22 +0100
Re: software disenchantment David Kleinecke <dkleinecke@gmail.com> - 2018-10-09 17:47 -0700
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-10 11:28 +0100
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-10 11:38 +0100
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-10 05:49 -0700
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-10 15:47 +0200
Re: software disenchantment "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-10 09:58 -0400
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-10 14:39 +0000
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-10 09:42 -0700
Re: software disenchantment "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-10 13:18 -0400
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-10 20:31 +0100
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-10 17:53 -0500
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-11 10:06 +0200
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 02:34 -0700
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-11 12:03 +0200
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 03:59 -0700
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-11 16:56 +0200
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 09:02 -0700
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-11 19:39 +0200
Re: software disenchantment Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-10-15 19:53 +0000
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-16 03:54 -0500
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 20:25 +0200
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 13:16 +0000
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 07:15 -0700
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-11 17:05 +0200
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 09:15 -0700
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 17:33 +0000
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-11 19:53 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 17:59 +0100
Re: software disenchantment nobody@example.org (Scott) - 2018-10-10 16:53 +0000
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-10 12:45 -0500
Re: software disenchantment Thiago Adams <thiago.adams@gmail.com> - 2018-10-10 11:04 -0700
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-10 14:22 -0500
Re: software disenchantment "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-10 15:53 -0400
Re: software disenchantment Ian Collins <ian-news@hotmail.com> - 2018-10-11 09:06 +1300
Re: software disenchantment "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-10 13:21 -0700
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-10 20:27 +0000
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-10 22:54 +0100
Re: software disenchantment Ian Collins <ian-news@hotmail.com> - 2018-10-11 11:01 +1300
Re: software disenchantment Ian Collins <ian-news@hotmail.com> - 2018-10-11 11:05 +1300
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-10 23:16 +0100
Re: software disenchantment Ian Collins <ian-news@hotmail.com> - 2018-10-11 11:22 +1300
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-10 23:28 +0100
Re: software disenchantment Ian Collins <ian-news@hotmail.com> - 2018-10-11 11:33 +1300
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 11:37 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 11:50 +0100
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 14:10 +0200
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 05:24 -0700
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 15:12 +0200
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 13:13 +0000
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 14:44 +0100
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 16:38 +0200
Re: software disenchantment mark.bluemel@gmail.com - 2018-10-11 08:09 -0700
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 17:43 +0100
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 17:36 +0000
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 18:56 +0100
Re: software disenchantment Keith Thompson <kst-u@mib.org> - 2018-10-11 11:54 -0700
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 20:09 +0100
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-12 13:10 +0000
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-13 12:57 +0200
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-11 14:27 -0500
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 22:03 +0200
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-11 15:56 -0500
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 11:30 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 23:34 +0100
Re: software disenchantment Keith Thompson <kst-u@mib.org> - 2018-10-11 16:24 -0700
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-12 01:46 +0100
Re: software disenchantment Keith Thompson <kst-u@mib.org> - 2018-10-11 18:58 -0700
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-12 08:50 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-12 11:12 +0100
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 12:55 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-12 12:10 +0100
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 13:29 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-12 13:06 +0100
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 14:30 +0200
Re: software disenchantment James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-10-12 08:53 -0400
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 15:11 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-12 13:55 +0100
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 15:13 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-12 16:10 +0100
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-12 15:22 +0000
Re: software disenchantment Keith Thompson <kst-u@mib.org> - 2018-10-12 09:12 -0700
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-13 13:00 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-13 12:52 +0100
Re: software disenchantment Ian Collins <ian-news@hotmail.com> - 2018-10-14 08:44 +1300
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-13 21:03 +0100
Re: software disenchantment Ian Collins <ian-news@hotmail.com> - 2018-10-14 10:13 +1300
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-13 23:02 +0100
Re: software disenchantment Keith Thompson <kst-u@mib.org> - 2018-10-13 16:47 -0700
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-14 01:05 +0100
Re: software disenchantment David Kleinecke <dkleinecke@gmail.com> - 2018-10-13 18:12 -0700
Re: software disenchantment Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-14 03:05 +0100
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-14 20:14 +0200
Re: software disenchantment Thiago Adams <thiago.adams@gmail.com> - 2018-10-14 11:25 -0700
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-12 13:17 +0000
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-12 13:16 +0000
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-12 14:36 +0100
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-12 14:25 +0000
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-12 15:55 +0100
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-12 15:22 +0000
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-12 08:26 -0700
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-12 15:51 +0000
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-13 13:06 +0200
Re: software disenchantment Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-10-15 19:30 +0000
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 12:39 +0200
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-12 08:44 +0200
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 13:01 +0200
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 20:41 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 20:02 +0100
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 22:13 +0200
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-11 13:03 -0500
Re: software disenchantment "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-11 11:33 -0700
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 21:04 +0200
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-11 20:15 -0500
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 13:17 +0200
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 13:10 +0000
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-10 19:22 -0500
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 10:58 +0200
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 02:37 -0700
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-11 12:06 +0200
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 04:00 -0700
Re: software disenchantment Cecil Bayona <cbayona@cbayona.com> - 2018-10-11 13:03 -0500
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 19:36 +0100
Re: software disenchantment Cecil Bayona <cbayona@cbayona.com> - 2018-10-11 15:37 -0500
Re: software disenchantment Thiago Adams <thiago.adams@gmail.com> - 2018-10-10 14:01 -0700
Re: software disenchantment Ian Collins <ian-news@hotmail.com> - 2018-10-11 09:02 +1300
Re: software disenchantment Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-10-10 19:11 +0000
Re: software disenchantment David Kleinecke <dkleinecke@gmail.com> - 2018-10-10 13:08 -0700
Re: software disenchantment Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-10-11 14:52 +0000
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 14:58 +0000
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-11 17:19 +0200
Re: software disenchantment Dan Purgert <dan@djph.net> - 2018-10-12 09:49 +0000
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-13 09:30 +0200
Re: software disenchantment Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-10-15 08:53 +0000
Re: software disenchantment Dan Purgert <dan@djph.net> - 2018-10-15 09:44 +0000
Re: software disenchantment Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2018-10-10 13:36 +0000
Re: software disenchantment "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-10-10 13:51 -0700
Re: software disenchantment nobody@example.org (Scott) - 2018-10-11 01:53 +0000
Re: software disenchantment Dan Purgert <dan@djph.net> - 2018-10-11 10:20 +0000
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 12:53 +0100
Re: software disenchantment "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-10-11 23:18 -0700
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2018-10-11 12:03 +0200 |
| Message-ID | <1oj39f-fgd.ln1@gangtai.home.grep.be> |
| In reply to | #136613 |
On 11/10/18 11:34, Malcolm McLean wrote: > On Thursday, October 11, 2018 at 9:08:37 AM UTC+1, Wouter Verhelst wrote: >> On 10/10/18 18:42, Malcolm McLean wrote: >>> When we compile this, we must have thirdparty.c, plus any dependencies. >> >> No, you do not. You must have the library that thirdparty.c was compiled >> into; either the shared one, or the static one. >> >> (if you're using thirdparty code that your build system needs to compile >> yourself, then yes, but why would you set up your build system to behave >> that way? Use the third party code's build system for that, that's what >> it's for, and then use the libraries that it yields) >> > Depending on libraries is a bad idea. No. *Hell* no. Even if I agreed with that though, if you want to integrate third-party source code, I'm sure that will still have its own build system? Then you have it build a static library (don't install it, just call the external build from your build so you get the external static library), and link to that. This will copy the third-party code. Problem solved, okay, move along now. > Generally it's better to integrate > third party source into your product. Then you don't have an external > dependency. External dependencies are not a problem. They are a benefit.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-10-11 03:59 -0700 |
| Message-ID | <9422ce95-5dc4-478b-bb21-391ce19eb7e6@googlegroups.com> |
| In reply to | #136618 |
On Thursday, October 11, 2018 at 11:09:54 AM UTC+1, Wouter Verhelst wrote: > On 11/10/18 11:34, Malcolm McLean wrote: > > On Thursday, October 11, 2018 at 9:08:37 AM UTC+1, Wouter Verhelst wrote: > >> On 10/10/18 18:42, Malcolm McLean wrote: > >>> When we compile this, we must have thirdparty.c, plus any dependencies. > >> > >> No, you do not. You must have the library that thirdparty.c was compiled > >> into; either the shared one, or the static one. > >> > >> (if you're using thirdparty code that your build system needs to compile > >> yourself, then yes, but why would you set up your build system to behave > >> that way? Use the third party code's build system for that, that's what > >> it's for, and then use the libraries that it yields) > >> > > Depending on libraries is a bad idea. > > No. > > *Hell* no. > > Even if I agreed with that though, if you want to integrate third-party > source code, I'm sure that will still have its own build system? Then > you have it build a static library (don't install it, just call the > external build from your build so you get the external static library), > and link to that. > > This will copy the third-party code. > > Problem solved, okay, move along now. > > > Generally it's better to integrate > > third party source into your product. Then you don't have an external > > dependency. > > External dependencies are not a problem. They are a benefit. > Third party code shouldn't have its own build system. Code should be written so that it can be dropped into any project, as source, and compiled. C++ is now going this way as increasingly components are distributed as headers. Precisely because the library dependency issue causes so many difficult problems. Every dependency is something else to locate, to be incompatible, to drag in another dependency, to fail to build correctly. This is what Bart has been complaining about.
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2018-10-11 16:56 +0200 |
| Message-ID | <du449f-hv5.ln1@gangtai.home.grep.be> |
| In reply to | #136626 |
On 11/10/18 12:59, Malcolm McLean wrote: > On Thursday, October 11, 2018 at 11:09:54 AM UTC+1, Wouter Verhelst wrote: >> On 11/10/18 11:34, Malcolm McLean wrote: >>> On Thursday, October 11, 2018 at 9:08:37 AM UTC+1, Wouter Verhelst wrote: >>>> On 10/10/18 18:42, Malcolm McLean wrote: >>>>> When we compile this, we must have thirdparty.c, plus any dependencies. >>>> >>>> No, you do not. You must have the library that thirdparty.c was compiled >>>> into; either the shared one, or the static one. >>>> >>>> (if you're using thirdparty code that your build system needs to compile >>>> yourself, then yes, but why would you set up your build system to behave >>>> that way? Use the third party code's build system for that, that's what >>>> it's for, and then use the libraries that it yields) >>>> >>> Depending on libraries is a bad idea. >> >> No. >> >> *Hell* no. >> >> Even if I agreed with that though, if you want to integrate third-party >> source code, I'm sure that will still have its own build system? Then >> you have it build a static library (don't install it, just call the >> external build from your build so you get the external static library), >> and link to that. >> >> This will copy the third-party code. >> >> Problem solved, okay, move along now. >> >>> Generally it's better to integrate >>> third party source into your product. Then you don't have an external >>> dependency. >> >> External dependencies are not a problem. They are a benefit. >> > Third party code shouldn't have its own build system. That... makes no sense. > Code should > be written so that it can be dropped into any project, as source, > and compiled. Well, if you like to be a masochist I won't stop you. But I tell you, if you consider third-party a black box beyond its header files, your life will be much easier. > C++ is now going this way as increasingly components are distributed > as headers. Precisely because the library dependency issue causes > so many difficult problems. Every dependency is something else to > locate, to be incompatible, to drag in another dependency, to fail > to build correctly. That's just a matter of ensuring your libraries are easy to install. This is a solved problem, with package managers on Linux and pkg-config to detect whether the libraries are available. Even on Windows, there are things like chocolatey to take the pain away. Having third-party dependencies does not make things harder, and should be encouraged.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-10-11 09:02 -0700 |
| Message-ID | <94ec50df-9bca-4daf-b190-470d8346112a@googlegroups.com> |
| In reply to | #136648 |
On Thursday, October 11, 2018 at 4:14:00 PM UTC+1, Wouter Verhelst wrote: > On 11/10/18 12:59, Malcolm McLean wrote: > > > > Third party code shouldn't have its own build system. > > That... makes no sense. > > > Code should > > be written so that it can be dropped into any project, as source, > > and compiled. > > Well, if you like to be a masochist I won't stop you. But I tell you, if > you consider third-party a black box beyond its header files, your life > will be much easier. > You frequently have to patch third party code. It depends obviously what it is, and these days you can often do it in collaboration with the author on github. Also, sometimes you need to raid the code, to get just one function without pulling everything else in, or to diagnose calls to it even if ultimately the third party code proves to be not the component at fault. Ideally you can treat it as a black box, yes. > > C++ is now going this way as increasingly components are distributed > > as headers. Precisely because the library dependency issue causes > > so many difficult problems. Every dependency is something else to > > locate, to be incompatible, to drag in another dependency, to fail > > to build correctly. > > That's just a matter of ensuring your libraries are easy to install. > This is a solved problem, with package managers on Linux and pkg-config > to detect whether the libraries are available. > > Even on Windows, there are things like chocolatey to take the pain away. > > Having third-party dependencies does not make things harder, and should > be encouraged. > Even if you can guarantee that all your users will use Linux, there's often, from experience, a lot of messing about with getting and updating dependencies. For example to install a library I had written myself I needed conan (because of the need for synchronisation with the version control). To install conan on the Linux box, I needed pip3 - which wasn't documented. To get pip3 I had to install via python3, after first going down a red herring route of compiling the latest version of python from source. It takes about a day to work out what you need and set everything up correctly, which is par for the course for a dependency. And this is using Linux. What if you need to run the code on a non-Linux system?
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2018-10-11 19:39 +0200 |
| Message-ID | <3ge49f-kic.ln1@gangtai.home.grep.be> |
| In reply to | #136658 |
On 11/10/18 18:02, Malcolm McLean wrote: > On Thursday, October 11, 2018 at 4:14:00 PM UTC+1, Wouter Verhelst wrote: >> On 11/10/18 12:59, Malcolm McLean wrote: >>> >>> Third party code shouldn't have its own build system. >> >> That... makes no sense. >> >>> Code should >>> be written so that it can be dropped into any project, as source, >>> and compiled. >> >> Well, if you like to be a masochist I won't stop you. But I tell you, if >> you consider third-party a black box beyond its header files, your life >> will be much easier. >> > You frequently have to patch third party code. Your "frequently" is obviously different from mine. Even so, the better (long-term) strategy is obviously to talk to whoever wrote that third-party code and ask them to accept your patches. That way, you can tell your users "please make sure you have version XYZ of the library". Once you've done that, it's not your problem anymore. > It depends obviously > what it is, and these days you can often do it in collaboration with > the author on github. Exactly. > Also, sometimes you need to raid the code, to > get just one function without pulling everything else in, or to diagnose > calls to it even if ultimately the third party code proves to be not > the component at fault. I'm not sure where the "one function" idea comes from; if you need one function, then just use the library already. The cost is usually very low. Yes, during development there might be cases where you may have to dig deeper into the library, rather than just using it. But once development has finished, there is no need to do so anymore. [...]>>> C++ is now going this way as increasingly components are distributed >>> as headers. Precisely because the library dependency issue causes >>> so many difficult problems. Every dependency is something else to >>> locate, to be incompatible, to drag in another dependency, to fail >>> to build correctly. >> >> That's just a matter of ensuring your libraries are easy to install. >> This is a solved problem, with package managers on Linux and pkg-config >> to detect whether the libraries are available. >> >> Even on Windows, there are things like chocolatey to take the pain away. >> >> Having third-party dependencies does not make things harder, and should >> be encouraged. >> > Even if you can guarantee that all your users will use Linux, there's > often, from experience, a lot of messing about with getting and updating > dependencies. Yes, and this is often more the case on users who use the more ancient distributions, like a five-year-old RedHat EL (or CentOS, which is essentially the same thing). In some cases, you may have to tell them "you can't do it on that system, we don't support that". I think that's perfectly fine. I'm also not saying it's a terrible idea to ship third-party code as part of your work in *all* cases. I've done so occasionally myself, too. But your statement that "Depending on libraries is a bad idea" in <e0fdf3f5-bd05-4867-809f-909e4b8cf256@googlegroups.com> is just wrong, and that's what I was reacting to. > For example to install a library I had written myself I > needed conan (because of the need for synchronisation with the version > control). To install conan on the Linux box, I needed pip3 - which wasn't > documented. To get pip3 I had to install via python3, after first going > down a red herring route of compiling the latest version of python > from source. There is usually little need to start compiling interpreters and whatnot, unless the code explicitly uses features of the interpreter which are not (yet) available in the packaged version of that interpreter for your OS. > It takes about a day to work out what you need and set > everything up correctly, which is par for the course for a dependency. In my experience, both as a developer and as a consumer of other people's code, if the README file documents what is needed and at what version, getting things together is usually fairly simple and easy to do. Yes, sometimes that means you have a bit of work. But "a day of work" is just exaggerating. An hour, at most, in my experience. > And this is using Linux. What if you need to run the code on a non-Linux > system? On mac, you can tell people to just use one of the many package managers. Those usually work pretty well, and will in most cases allow you to get the libraries you need with a minimum of fuss. Yes, on Windows they're usually shit outta luck.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-10-15 19:53 +0000 |
| Message-ID | <slrnps9s1e.f78.grahn+nntp@frailea.sa.invalid> |
| In reply to | #136673 |
On Thu, 2018-10-11, Wouter Verhelst wrote: > On 11/10/18 18:02, Malcolm McLean wrote: ... >> Even if you can guarantee that all your users will use Linux, there's >> often, from experience, a lot of messing about with getting and updating >> dependencies. > > Yes, and this is often more the case on users who use the more ancient > distributions, like a five-year-old RedHat EL (or CentOS, which is > essentially the same thing). In some cases, you may have to tell them > "you can't do it on that system, we don't support that". I think that's > perfectly fine. Yes. I think it needs explaining a bit more, for the benefit of the Windows minority: If you're on Unix (not just Linux) and the library you're looking at is free software, widely used, maintained and stable, using it is a no-brainer; it's about as hard as using the standard C library. Lots of libraries fall into this category. ... >> For example to install a library I had written myself I >> needed conan (because of the need for synchronisation with the version >> control). To install conan on the Linux box, I needed pip3 - which wasn't >> documented. To get pip3 I had to install via python3, after first going >> down a red herring route of compiling the latest version of python >> from source. That's the start of the kind of hell described in https://xkcd.com/1987/ . I agree that it's painful, and should be avoided, but it's completely unlike depending on a stable, well-known library. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2018-10-16 03:54 -0500 |
| Message-ID | <pq48uv$r4p$1@news.albasani.net> |
| In reply to | #136794 |
On 10/15/2018 2:53 PM, Jorgen Grahn wrote: > On Thu, 2018-10-11, Wouter Verhelst wrote: >> On 11/10/18 18:02, Malcolm McLean wrote: > ... >>> Even if you can guarantee that all your users will use Linux, there's >>> often, from experience, a lot of messing about with getting and updating >>> dependencies. >> >> Yes, and this is often more the case on users who use the more ancient >> distributions, like a five-year-old RedHat EL (or CentOS, which is >> essentially the same thing). In some cases, you may have to tell them >> "you can't do it on that system, we don't support that". I think that's >> perfectly fine. > > Yes. I think it needs explaining a bit more, for the benefit of the > Windows minority: > > If you're on Unix (not just Linux) and the library you're looking at > is free software, widely used, maintained and stable, using it is a > no-brainer; it's about as hard as using the standard C library. > > Lots of libraries fall into this category. > On Windows (excluding Cygwin), you get (more or less) for free: The C standard library; The Win32 API (in various subsets and flavors); OpenGL. DirectX, while canonically part of Windows, generally requires installing and using the DirectX SDK, which (for whatever reason) doesn't automatically integrate with the Visual Studio installation or with the Windows SDK (unless they fixed it since last I looked). There are also some APIs which exist purely as COM+ interfaces, but if using these (at which point portability is already blown), almost easier to just write this part of the program in C# or similar (because P/Invoke or C++/CLI is at least mildly less annoying). One can also write code in the common subset of Linux and Windows, which basically just means C stdlib and OS specific wrapper code. However, one may soon observe that, if the relevant parts of the C library are also wrapped (or shimmed in when needed), there isn't a huge difference between hosted development and bare metal. Typically C stdlib wrapping is for other reasons, file IO already ends up wrapped (eg for VFS or async IO), ... (*1) For example, in a recent experiment of trying to port my 3D engine to my custom ISA (work on this is still ongoing), I mostly just had to drag along the OpenGL headers. The engine doesn't actually need OpenGL in this case, but the software renderer exposes itself as an OpenGL miniport (so, there is still a dependence on the contents of the OpenGL headers). *1: There is often still a dependence on various C library functions, but OTOH for example in my C compiler (which normally runs on top of an OS), I ended up largely replacing a lot of C library functions (like sprintf and str*) with more specialized alternatives. Currently I have it able to build ~300 kLOC in ~8 seconds (with compiler built as debug), or ~4 seconds (optimized). Though, this was along with more conventional optimizations, like replacing linear searches with hash tables or binary searches. Also things replacing the use of selection-sort for sorting switch/case labels with quicksort, ... It was taking approx 37 seconds before I started beating on all this. Time needed to rebuild Doom: ~1.7s (opt; not much of a change from before). > ... >>> For example to install a library I had written myself I >>> needed conan (because of the need for synchronisation with the version >>> control). To install conan on the Linux box, I needed pip3 - which wasn't >>> documented. To get pip3 I had to install via python3, after first going >>> down a red herring route of compiling the latest version of python >>> from source. > > That's the start of the kind of hell described in https://xkcd.com/1987/ . > I agree that it's painful, and should be avoided, but it's completely > unlike depending on a stable, well-known library. > I prefer the self-contained minimalist style, generally plain C with a mostly C95 like subset, sort of like Doom, Quake, and my various projects.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-11 20:25 +0200 |
| Message-ID | <ppo4i5$73j$1@dont-email.me> |
| In reply to | #136648 |
On 11/10/18 16:56, Wouter Verhelst wrote: > On 11/10/18 12:59, Malcolm McLean wrote: >> On Thursday, October 11, 2018 at 11:09:54 AM UTC+1, Wouter Verhelst wrote: >>> On 11/10/18 11:34, Malcolm McLean wrote: >>>> On Thursday, October 11, 2018 at 9:08:37 AM UTC+1, Wouter Verhelst wrote: >>>>> On 10/10/18 18:42, Malcolm McLean wrote: >>>>>> When we compile this, we must have thirdparty.c, plus any dependencies. >>>>> >>>>> No, you do not. You must have the library that thirdparty.c was compiled >>>>> into; either the shared one, or the static one. >>>>> >>>>> (if you're using thirdparty code that your build system needs to compile >>>>> yourself, then yes, but why would you set up your build system to behave >>>>> that way? Use the third party code's build system for that, that's what >>>>> it's for, and then use the libraries that it yields) >>>>> >>>> Depending on libraries is a bad idea. >>> >>> No. >>> >>> *Hell* no. >>> >>> Even if I agreed with that though, if you want to integrate third-party >>> source code, I'm sure that will still have its own build system? Then >>> you have it build a static library (don't install it, just call the >>> external build from your build so you get the external static library), >>> and link to that. >>> >>> This will copy the third-party code. >>> >>> Problem solved, okay, move along now. >>> >>>> Generally it's better to integrate >>>> third party source into your product. Then you don't have an external >>>> dependency. >>> >>> External dependencies are not a problem. They are a benefit. >>> >> Third party code shouldn't have its own build system. > > That... makes no sense. > >> Code should >> be written so that it can be dropped into any project, as source, >> and compiled. > > Well, if you like to be a masochist I won't stop you. But I tell you, if > you consider third-party a black box beyond its header files, your life > will be much easier. > I'm guessing that people are talking about different kinds of third-party code, in different circumstances. For some code, you want to view the third-party code as a black box - track it independently, built it with whatever build tools it has (or use the provided binaries), and attach it to your own code using the documented ABI. For other types, you want to add the source to your own files, keep it there in the same source code repository, compile it together with the same options, use the code in debugging, etc. Both methods have their place.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-10-11 13:16 +0000 |
| Message-ID | <J2IvD.102472$9O2.13907@fx03.iad> |
| In reply to | #136613 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >On Thursday, October 11, 2018 at 9:08:37 AM UTC+1, Wouter Verhelst wrote: >> On 10/10/18 18:42, Malcolm McLean wrote: >> > When we compile this, we must have thirdparty.c, plus any dependencies. >> >> No, you do not. You must have the library that thirdparty.c was compiled >> into; either the shared one, or the static one. >> >> (if you're using thirdparty code that your build system needs to compile >> yourself, then yes, but why would you set up your build system to behave >> that way? Use the third party code's build system for that, that's what >> it's for, and then use the libraries that it yields) >> >Depending on libraries is a bad idea. Generally it's better to integrate >third party source into your product. Then you don't have an external >dependency. You almost _never_ get that choice, unless it is open source. In our field, all the third-party code costs $$ and comes only in object form (e.g. Synopsis, Cadence, Tensilica, et alia) and often requiring a on-site license manager with a limited set of supported linux releases (generally Redhat/Centos for the tool vendors).
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-10-11 07:15 -0700 |
| Message-ID | <02f7970b-a243-437a-8339-74c4a64c105b@googlegroups.com> |
| In reply to | #136635 |
On Thursday, October 11, 2018 at 2:16:34 PM UTC+1, Scott Lurndal wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >On Thursday, October 11, 2018 at 9:08:37 AM UTC+1, Wouter Verhelst wrote: > >> On 10/10/18 18:42, Malcolm McLean wrote: > >> > When we compile this, we must have thirdparty.c, plus any dependencies. > >> > >> No, you do not. You must have the library that thirdparty.c was compiled > >> into; either the shared one, or the static one. > >> > >> (if you're using thirdparty code that your build system needs to compile > >> yourself, then yes, but why would you set up your build system to behave > >> that way? Use the third party code's build system for that, that's what > >> it's for, and then use the libraries that it yields) > >> > >Depending on libraries is a bad idea. Generally it's better to integrate > >third party source into your product. Then you don't have an external > >dependency. > > You almost _never_ get that choice, unless it is open source. In our > field, all the third-party code costs $$ and comes only in object form > (e.g. Synopsis, Cadence, Tensilica, et alia) and often requiring a > on-site license manager with a limited set of supported linux releases > (generally Redhat/Centos for the tool vendors). > In science most people make their good code available. Of course one feature of a library is that the source is inaccessible, which can be good for the vendor, but not for the purchaser (except that by keeping commercial secrets he keeps the vendor in business).
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2018-10-11 17:05 +0200 |
| Message-ID | <sd549f-qe6.ln1@gangtai.home.grep.be> |
| In reply to | #136639 |
On 11/10/18 16:15, Malcolm McLean wrote: > On Thursday, October 11, 2018 at 2:16:34 PM UTC+1, Scott Lurndal wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>> On Thursday, October 11, 2018 at 9:08:37 AM UTC+1, Wouter Verhelst wrote: >>>> On 10/10/18 18:42, Malcolm McLean wrote: >>>>> When we compile this, we must have thirdparty.c, plus any dependencies. >>>> >>>> No, you do not. You must have the library that thirdparty.c was compiled >>>> into; either the shared one, or the static one. >>>> >>>> (if you're using thirdparty code that your build system needs to compile >>>> yourself, then yes, but why would you set up your build system to behave >>>> that way? Use the third party code's build system for that, that's what >>>> it's for, and then use the libraries that it yields) >>>> >>> Depending on libraries is a bad idea. Generally it's better to integrate >>> third party source into your product. Then you don't have an external >>> dependency. >> >> You almost _never_ get that choice, unless it is open source. In our >> field, all the third-party code costs $$ and comes only in object form >> (e.g. Synopsis, Cadence, Tensilica, et alia) and often requiring a >> on-site license manager with a limited set of supported linux releases >> (generally Redhat/Centos for the tool vendors). >> > In science most people make their good code available. > > Of course one feature of a library is that the source is inaccessible, > which can be good for the vendor, but not for the purchaser (except that > by keeping commercial secrets he keeps the vendor in business). There are many good features about (shared) libraries: - Updates become decoupled. When a security issue exists in a third-party tool which you're shipping as part of your product, you have to ensure that you keep on top of those things, and possibly do a new release when the inevitable critical bug fix happens there. With libraries, you don't need to do that, you just allow the library to be updated, and you're done. It's just been turned into someone else's problem (and that's a good thing) - A more generic version of the same problem is that when you copy external code into your program, that external code becomes an extra maintenance burden for you. If you use the shared library, you just tell your users "use this shared library over here", and you're done. Now it's no longer a maintenance burden, and you can focus on the things that are actually *your* code. - When multiple different applications use the same shared library, the OS can read the library from disk only once, but map them into each application's address space. You don't get that with copying third-party code into your program. - Bundling third-party code makes the set of code that *you* have to ship to people using your code much larger. With a package manager, you can just declare a dependency on the necessary libraries, and then the OS will install them for your users when they install your software. This means you don't have to worry about that. Really. Use libraries. They work. They're helpful.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-10-11 09:15 -0700 |
| Message-ID | <02b9558d-3533-4701-bd62-00d1c48139b3@googlegroups.com> |
| In reply to | #136649 |
On Thursday, October 11, 2018 at 4:14:00 PM UTC+1, Wouter Verhelst wrote: > On 11/10/18 16:15, Malcolm McLean wrote: > > On Thursday, October 11, 2018 at 2:16:34 PM UTC+1, Scott Lurndal wrote: > >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >>> On Thursday, October 11, 2018 at 9:08:37 AM UTC+1, Wouter Verhelst wrote: > >>>> On 10/10/18 18:42, Malcolm McLean wrote: > >>>>> When we compile this, we must have thirdparty.c, plus any dependencies. > >>>> > >>>> No, you do not. You must have the library that thirdparty.c was compiled > >>>> into; either the shared one, or the static one. > >>>> > >>>> (if you're using thirdparty code that your build system needs to compile > >>>> yourself, then yes, but why would you set up your build system to behave > >>>> that way? Use the third party code's build system for that, that's what > >>>> it's for, and then use the libraries that it yields) > >>>> > >>> Depending on libraries is a bad idea. Generally it's better to integrate > >>> third party source into your product. Then you don't have an external > >>> dependency. > >> > >> You almost _never_ get that choice, unless it is open source. In our > >> field, all the third-party code costs $$ and comes only in object form > >> (e.g. Synopsis, Cadence, Tensilica, et alia) and often requiring a > >> on-site license manager with a limited set of supported linux releases > >> (generally Redhat/Centos for the tool vendors). > >> > > In science most people make their good code available. > > > > Of course one feature of a library is that the source is inaccessible, > > which can be good for the vendor, but not for the purchaser (except that > > by keeping commercial secrets he keeps the vendor in business). > > There are many good features about (shared) libraries: > - Updates become decoupled. When a security issue exists in a > third-party tool which you're shipping as part of your product, you have > to ensure that you keep on top of those things, and possibly do a new > release when the inevitable critical bug fix happens there. With > libraries, you don't need to do that, you just allow the library to be > updated, and you're done. It's just been turned into someone else's > problem (and that's a good thing) > - A more generic version of the same problem is that when you copy > external code into your program, that external code becomes an extra > maintenance burden for you. If you use the shared library, you just tell > your users "use this shared library over here", and you're done. Now > it's no longer a maintenance burden, and you can focus on the things > that are actually *your* code. > - When multiple different applications use the same shared library, the > OS can read the library from disk only once, but map them into each > application's address space. You don't get that with copying third-party > code into your program. > - Bundling third-party code makes the set of code that *you* have to > ship to people using your code much larger. With a package manager, you > can just declare a dependency on the necessary libraries, and then the > OS will install them for your users when they install your software. > This means you don't have to worry about that. > > Really. Use libraries. They work. They're helpful. > You're less likely to have a security issue if you don't link to any third party libraries, because exploits are usually done by looking at the third party binaries. You don't need to "maintain" code unless someone else is making changes somewhere. Like updating a third party library. If code works, it will work forever, as long as you don't change the context. On small machines or with massive libraries the shared address space might be a benefit. But RAM is very cheap now, few programs fail because machines don't have the memory to hold their executable code. The OS will install all the dependencies. Which is great. Until the system breaks. Then you find that because everyone has been relying on the automatic system, they don't know how to do it manually any more. So now the system is very hard to fix. For example, a few years back, someone published an analysis of DNA sequence alignment tools. In the paper, they said that 50% of the tools had been excluded from the analysis because it was impossible to install and run them.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-10-11 17:33 +0000 |
| Message-ID | <gPLvD.288743$Ac3.7233@fx45.iad> |
| In reply to | #136659 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >On Thursday, October 11, 2018 at 4:14:00 PM UTC+1, Wouter Verhelst wrote: >> Really. Use libraries. They work. They're helpful. >> >You're less likely to have a security issue if you don't link to any >third party libraries, because exploits are usually done by looking >at the third party binaries. You're less likely to have a security issue if you don't use microsoft operating systems and their screwy dll setup. Really. What Wouter said.
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2018-10-11 19:53 +0200 |
| Message-ID | <u8f49f-r0d.ln1@gangtai.home.grep.be> |
| In reply to | #136659 |
On 11/10/18 18:15, Malcolm McLean wrote: > On Thursday, October 11, 2018 at 4:14:00 PM UTC+1, Wouter Verhelst wrote: >> On 11/10/18 16:15, Malcolm McLean wrote: >>> On Thursday, October 11, 2018 at 2:16:34 PM UTC+1, Scott Lurndal wrote: >>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>>> On Thursday, October 11, 2018 at 9:08:37 AM UTC+1, Wouter Verhelst wrote: >>>>>> On 10/10/18 18:42, Malcolm McLean wrote: >>>>>>> When we compile this, we must have thirdparty.c, plus any dependencies. >>>>>> >>>>>> No, you do not. You must have the library that thirdparty.c was compiled >>>>>> into; either the shared one, or the static one. >>>>>> >>>>>> (if you're using thirdparty code that your build system needs to compile >>>>>> yourself, then yes, but why would you set up your build system to behave >>>>>> that way? Use the third party code's build system for that, that's what >>>>>> it's for, and then use the libraries that it yields) >>>>>> >>>>> Depending on libraries is a bad idea. Generally it's better to integrate >>>>> third party source into your product. Then you don't have an external >>>>> dependency. >>>> >>>> You almost _never_ get that choice, unless it is open source. In our >>>> field, all the third-party code costs $$ and comes only in object form >>>> (e.g. Synopsis, Cadence, Tensilica, et alia) and often requiring a >>>> on-site license manager with a limited set of supported linux releases >>>> (generally Redhat/Centos for the tool vendors). >>>> >>> In science most people make their good code available. >>> >>> Of course one feature of a library is that the source is inaccessible, >>> which can be good for the vendor, but not for the purchaser (except that >>> by keeping commercial secrets he keeps the vendor in business). >> >> There are many good features about (shared) libraries: >> - Updates become decoupled. When a security issue exists in a >> third-party tool which you're shipping as part of your product, you have >> to ensure that you keep on top of those things, and possibly do a new >> release when the inevitable critical bug fix happens there. With >> libraries, you don't need to do that, you just allow the library to be >> updated, and you're done. It's just been turned into someone else's >> problem (and that's a good thing) >> - A more generic version of the same problem is that when you copy >> external code into your program, that external code becomes an extra >> maintenance burden for you. If you use the shared library, you just tell >> your users "use this shared library over here", and you're done. Now >> it's no longer a maintenance burden, and you can focus on the things >> that are actually *your* code. >> - When multiple different applications use the same shared library, the >> OS can read the library from disk only once, but map them into each >> application's address space. You don't get that with copying third-party >> code into your program. >> - Bundling third-party code makes the set of code that *you* have to >> ship to people using your code much larger. With a package manager, you >> can just declare a dependency on the necessary libraries, and then the >> OS will install them for your users when they install your software. >> This means you don't have to worry about that. >> >> Really. Use libraries. They work. They're helpful. >> > You're less likely to have a security issue if you don't link to any > third party libraries, because exploits are usually done by looking > at the third party binaries. Not really. What do you mean by "security issue"? If you mean "you're unlikely to have a situation where people will use your program to break into a system", then you might be right, although it's probably only true if you expect that only a handful of people will ever use your code. You're also guessing that nobody ever cares, which is the "I'm not a target" argument in security, and which has been proven wrong over and over again. If you mean "you're unlikely to end up with code that can possibly be exploited", then you're claiming that you're the best programmer in the world who never makes any mistakes, and that your newly-written code will have less gaping security holes than any code out there which has existed for a while already and has been battle-tested. It's pretty arrogant and pretty obviously wrong. > You don't need to "maintain" code unless someone else is making changes > somewhere. Like updating a third party library. If code works, it will > work forever, as long as you don't change the context. "maintaining" doesn't just mean "adding new features", although that's part of it; it also means "removing bugs". Third-party code is likely to be better tested and more readily available than whatever you write yourself, but it is also likely to not be perfect. If some of its imperfections impact the functionality of your software, then now suddenly you'll have to either update to the next level (work), or find and fix the bug yourself (work). If the third-party code is external, however, you may find that the bug has already been fixed in a more recent version of the library (so you just tell your users to upgrade, which is no work for you), or if not, you can inform the maintainer of that code of the bug, who may then fix it in their code (also no work). > On small machines or with massive libraries the shared address space > might be a benefit. But RAM is very cheap now, The "X is very cheap now" argument, for any of RAM, disk space, or CPU power, is one that gets abused a lot; it's always been true -- that is, today's X will always be cheaper than last year's X for the same size or performance -- but that has never meant that the benefits disappear, because software also gets larger and slower, and more of it is run on the same system. Also, "more stuff fits in memory" is not the only benefit of sharing address space; if you have a library that gets used a lot, then it is more likely to be in your CPU caches, for instance, which is good for performance. > few programs fail because > machines don't have the memory to hold their executable code. True, but machines *do* slow down because they don't have enough memory. > The OS will install all the dependencies. Which is great. Until the > system breaks. Then you find that because everyone has been relying on > the automatic system, they don't know how to do it manually any more. > So now the system is very hard to fix. For example, a few years back, > someone published an analysis of DNA sequence alignment tools. In > the paper, they said that 50% of the tools had been excluded from the > analysis because it was impossible to install and run them. Yes, in the scientific world, there is a lot of throwaway code where people write some hackish code to prove a point, then write a paper and don't care about the software anymore, because the paper is what matters, not the software. I'm not talking about that world.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-11 17:59 +0100 |
| Message-ID | <1kLvD.18129$RM7.12540@fx24.am4> |
| In reply to | #136613 |
On 11/10/2018 10:34, Malcolm McLean wrote: > On Thursday, October 11, 2018 at 9:08:37 AM UTC+1, Wouter Verhelst wrote: >> On 10/10/18 18:42, Malcolm McLean wrote: >>> When we compile this, we must have thirdparty.c, plus any dependencies. >> >> No, you do not. You must have the library that thirdparty.c was compiled >> into; either the shared one, or the static one. >> >> (if you're using thirdparty code that your build system needs to compile >> yourself, then yes, but why would you set up your build system to behave >> that way? Use the third party code's build system for that, that's what >> it's for, and then use the libraries that it yields) >> > Depending on libraries is a bad idea. Generally it's better to integrate > third party source into your product. Then you don't have an external > dependency. There are several problems with that: (1) Good luck trying to get the source code of the Windows API functions (and which themselves need other parts of Windows in source form). (2) The library might be in a different language (3) Because other people's programs tend to be huge (eg. 100Mloc for Windows, but in any case usually dwarfing my own program), they will put undue pressure on your build process (4) Your executable programs will be huge. And N programs using the same library will have N copies of the library. Having separate libraries in binary form (eg. in cross-language DLL format on Windows) is desirable. And my tools depend on that. -- bart
[toc] | [prev] | [next] | [standalone]
| From | nobody@example.org (Scott) |
|---|---|
| Date | 2018-10-10 16:53 +0000 |
| Message-ID | <5bbe2a68.2037478234@news.xmission.com> |
| In reply to | #136526 |
On Wed, 10 Oct 2018 05:49:21 -0700 (PDT), Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: >On Wednesday, October 10, 2018 at 11:39:11 AM UTC+1, Bart wrote: >> On 10/10/2018 11:28, Bart wrote: >> >> > Then you /are/ looking at a cut-down C, but you wouldn't cut down >> > essentials such as for and while loops. You would get rid of most of the >> > processor >> >> I mean most of the preprocessor. >> >> Getting rid of the processor would be rather drastic. >> >We need to get rid of the "sticky" rule with C. The rule that means you have >to pull in a system header which includes dozens of other headers, just >because you need the symbol "DWORD" for some reason. >How to do that isn't obvious. What I'm seeing here isn't an argument against C, it's an argument against the clumsy and foolish ways that people have used it. I'd be the first to agree that some C implementations are nightmarish abominations -- but that's a problem with a specific implementation, not with C as such. People have gone on to create many languages that variously attempt to correct C's shortcomings; some have had some success, most have faded to obscurity. Yet C itself persists. In light of this a fellow, a smart fellow, might take a break from looking at what's wrong with C, and take a moment to reflect on what's right with C.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2018-10-10 12:45 -0500 |
| Message-ID | <ppldrc$n44$1@news.albasani.net> |
| In reply to | #136526 |
On 10/10/2018 7:49 AM, Malcolm McLean wrote: > On Wednesday, October 10, 2018 at 11:39:11 AM UTC+1, Bart wrote: >> On 10/10/2018 11:28, Bart wrote: >> >>> Then you /are/ looking at a cut-down C, but you wouldn't cut down >>> essentials such as for and while loops. You would get rid of most of the >>> processor >> >> I mean most of the preprocessor. >> >> Getting rid of the processor would be rather drastic. >> > We need to get rid of the "sticky" rule with C. The rule that means you have > to pull in a system header which includes dozens of other headers, just > because you need the symbol "DWORD" for some reason. > How to do that isn't obvious. > One "possible" option is partly replacing header inclusion with database-like metadata, but pulling this off effectively without breaking things in the language is harder. For example, compiling Doom in my case (with my compiler for my ISA), it is (currently) averaging about 9ms per translation unit for header inclusion (for an overall compile time of around 2.9 seconds); skipping preprocessing could theoretically save ~ 0.6 seconds overall, and roughly 45% of the time spent in the frontend (possibly itself a little faster due to not needing to deal with all of the stuff pulled in from headers). Though, in this process, 1.1s is currently spent mostly in codegen, and ~ 0.7s is spent in file-loading (mostly IO). Note that each header is loaded once and then added to a cache (with ASCII/UTF-8/16 normalization done when the file is initially read-in). I once considered a VFS for system headers, but haven't done so yet as the savings may not be worth the hassle involved. Fewer obvious ways to speed up the codegen; a lot of the time is apparently spent mostly in the register allocator and logic for dealing with labels and similar (followed by misc stuff like emitting words to sections and performing relocs). There is no ASM stage, and doing ASM output currently takes ~ 3.5s, in which case a bunch of time is spent mostly in the C++ code inside of MSVCRT's sprintf implementation (if it mattered, could experiment with doing a more specialized 'sprintf'). Optional operations, like dumping AST's or 3AC IR output may also add considerably to the overall running time. Building the compiler with optimizations enabled reduces overall build time to ~ 1.7s (still spends ~ 0.7s in IO), with ~ 3ms per TU for preprocessing, ... All this seems fairly acceptable.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-10-10 11:04 -0700 |
| Message-ID | <5c209401-54a3-410d-85fd-a5bc50ba93ca@googlegroups.com> |
| In reply to | #136565 |
On Wednesday, October 10, 2018 at 2:45:28 PM UTC-3, BGB wrote: > On 10/10/2018 7:49 AM, Malcolm McLean wrote: > > On Wednesday, October 10, 2018 at 11:39:11 AM UTC+1, Bart wrote: > >> On 10/10/2018 11:28, Bart wrote: > >> > >>> Then you /are/ looking at a cut-down C, but you wouldn't cut down > >>> essentials such as for and while loops. You would get rid of most of the > >>> processor > >> > >> I mean most of the preprocessor. > >> > >> Getting rid of the processor would be rather drastic. > >> > > We need to get rid of the "sticky" rule with C. The rule that means you have > > to pull in a system header which includes dozens of other headers, just > > because you need the symbol "DWORD" for some reason. > > How to do that isn't obvious. > > > > One "possible" option is partly replacing header inclusion with > database-like metadata, but pulling this off effectively without > breaking things in the language is harder. I like the #ifdef mechanism. In C++ modules or in your database-like how do you deal with different compilation settings? We would need many metatada for each combination of settings. The solution is pre-compiled headers. We still have the "source" and the pre-compiled headers can optimize the parser.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2018-10-10 14:22 -0500 |
| Message-ID | <ppljgb$8jc$1@news.albasani.net> |
| In reply to | #136567 |
On 10/10/2018 1:04 PM, Thiago Adams wrote: > On Wednesday, October 10, 2018 at 2:45:28 PM UTC-3, BGB wrote: >> On 10/10/2018 7:49 AM, Malcolm McLean wrote: >>> On Wednesday, October 10, 2018 at 11:39:11 AM UTC+1, Bart wrote: >>>> On 10/10/2018 11:28, Bart wrote: >>>> >>>>> Then you /are/ looking at a cut-down C, but you wouldn't cut down >>>>> essentials such as for and while loops. You would get rid of most of the >>>>> processor >>>> >>>> I mean most of the preprocessor. >>>> >>>> Getting rid of the processor would be rather drastic. >>>> >>> We need to get rid of the "sticky" rule with C. The rule that means you have >>> to pull in a system header which includes dozens of other headers, just >>> because you need the symbol "DWORD" for some reason. >>> How to do that isn't obvious. >>> >> >> One "possible" option is partly replacing header inclusion with >> database-like metadata, but pulling this off effectively without >> breaking things in the language is harder. > > I like the #ifdef mechanism. > > In C++ modules or in your database-like how do you deal > with different compilation settings? > We would need many metatada for each combination of settings. > > The solution is pre-compiled headers. We still have the "source" > and the pre-compiled headers can optimize the parser. > The header source would still exist in such a database, just it wouldn't be used directly by the "#include" mechanism when including a "header" which exists within this database. In a previous attempt, I had split up ifdef's into two different groups (depending on the define): those which were still handled during preprocessing, and those which were "delayed" until a later stage in the compiler (effectively, they were translated to a different syntax). All of the relevant branches would then be compiled just with attributes encoding which defines a given declaration or code-block depends on, ... With N/A contents being pruned away in the compiler's backend). The problem was that this imposed constraints on how this feature could be used (*) and still didn't adequately address some issues I had initially set out to "solve" (like a single binary working with different C library implementations or OS APIs; at best case the C library would need a wrapper or for the compiler to provide its own C library and similar). *: For example, everything within the block had to be "syntactically valid" on its own, couldn't be used for macro expansion, required types to exist regardless of whether or not the block was used, ... This latter limitation was a big mess for, say, having sections of code specific to Win32 or the POSIX APIs, since these would depend on headers/types/... which may or may not exist depending on the target. This limitation effectively ruined its usability for one of its main potential use-cases (since everything for every target will need to exist during building, which would mean building with both Windows and POSIX headers at the same time; neither of which exist in forms to be aware of or deal gracefully with the quirks of this mechanism; as we don't want Win32 stuff polluting a POSIX target or the reverse). The result would be needing effectively an abstract wrapper library over the OS specific APIs, basically defeating the whole point. Not long after, I more or less gave up on this idea. Some more narrowly defined conditions can be addressed via more constrained mechanisms; such as using 'unsigned long' for "size_t" which can automagically vary to be the correct size for using the same IL code for 32 and 64-bit builds (with a common C library impl), mostly because things like struct layout and similar aren't fixed until after the 3AC is generated. Similarly, differences in the ASM modules (between 32 and 64 bit ISA variants or for dealing with optional ISA features; or entirely separate ISA's if need be) can be handled by using a secondary ".ifdef" mechanism which was handled much later (during ASM parsing; by which stage these specifics are known), vs during the normal preprocessing stage (which happens prior to producing the IL). So, in a much more limited form of the original idea still exists for the assembler.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-10 15:53 -0400 |
| Message-ID | <ppllbg$bkr$1@dont-email.me> |
| In reply to | #136569 |
On 10/10/2018 3:22 PM, BGB wrote: > On 10/10/2018 1:04 PM, Thiago Adams wrote: >> The solution is pre-compiled headers. We still have the "source" >> and the pre-compiled headers can optimize the parser. Pre-compiled headers don't always get you there. You can have pre-parsed headers, but even then if a #define comes into play which re-defines something referenced somewhere, your pre- compiled header will be invalid and may require a full repars- ing anyway. The ability to have random #define values, and conditional compilation makes it unfeasible outside of a certain type of system. > The header source would still exist in such a database, just it wouldn't be > used directly by the "#include" mechanism when including a "header" which > exists within this database. > > In a previous attempt, I had split up ifdef's into two different groups > (depending on the define): those which were still handled during > preprocessing, and those which were "delayed" until a later stage in the > compiler (effectively, they were translated to a different syntax). All of > the relevant branches would then be compiled just with attributes encoding > which defines a given declaration or code-block depends on, ... With N/A > contents being pruned away in the compiler's backend). > > The problem was that this imposed constraints on how this feature could be > used (*) and still didn't adequately address some issues I had initially set > out to "solve" (like a single binary working with different C library > implementations or OS APIs; at best case the C library would need a wrapper > or for the compiler to provide its own C library and similar). > > > *: For example, everything within the block had to be "syntactically valid" > on its own, couldn't be used for macro expansion, required types to exist > regardless of whether or not the block was used, ... > > This latter limitation was a big mess for, say, having sections of code > specific to Win32 or the POSIX APIs, since these would depend on > headers/types/... which may or may not exist depending on the target. This > limitation effectively ruined its usability for one of its main potential > use-cases (since everything for every target will need to exist during > building, which would mean building with both Windows and POSIX headers at > the same time; neither of which exist in forms to be aware of or deal > gracefully with the quirks of this mechanism; as we don't want Win32 stuff > polluting a POSIX target or the reverse). > > The result would be needing effectively an abstract wrapper library over the > OS specific APIs, basically defeating the whole point. > > Not long after, I more or less gave up on this idea. The solution is to tokenize every word in every #include file used in the system, and store it all in a B+tree type index for quick access by name. As something changes, once you have the name, you reference the lines which relate to the token and see if the change impacts compilation. Then, each thing that is changed spawns its own separate child lookup to look for more that needs compilation, and it repeats until it exhausts itself. And if you get beyond some number of N things that need to be re-compiled, it may be quicker to stop the examination and do a full recompile, so that has to have a threshold there, examined from prior compile times, etc. This all exists as an identifying algorithm to determine what needs to be re-compiled based on what's changed in the source code. Some things impact entire functions, such as adding new local variables, which will change the stack alignment, and may impact the stack history in the running ABI if some recursion is in play, etc. It's all very logical, but it's all very meticulous, and very memory intensive. It would work for projects that are a few 100K lines of code max, with minimal output files (DLLs and EXE files). Beyond that, you'd be better off to do full compiles and a more traditional software development cycle. I do not plan to ever have projects more than a few hundred thousand lines of code each. > Some more narrowly defined conditions can be addressed via more constrained > mechanisms; such as using 'unsigned long' for "size_t" which can > automagically vary to be the correct size for using the same IL code for 32 > and 64-bit builds (with a common C library impl), mostly because things like > struct layout and similar aren't fixed until after the 3AC is generated. > > Similarly, differences in the ASM modules (between 32 and 64 bit ISA variants > or for dealing with optional ISA features; or entirely separate ISA's if need > be) can be handled by using a secondary ".ifdef" mechanism which was handled > much later (during ASM parsing; by which stage these specifics are known), vs > during the normal preprocessing stage (which happens prior to producing the IL). > > So, in a much more limited form of the original idea still exists for the > assembler. For me, the goals are always to look at things from the developer's point of view. What would he/she need tool-wise to make their job easier. And even if it's harder for me to get it setup for them, I am one person (or we would be one team) working on the compiler end, and there may be thousands of developers who later use this tool. The extra investment of thought and labor results in a desired end- result of a feature-rich tool more people can use to be productive. It will save them time, which when multiplied out and compared to my extra time, will make mine seem small by comparison. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web