Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #106559
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Linker question |
| Date | 2017-03-20 13:51 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <87r31soy41.fsf@bsb.me.uk> (permalink) |
| References | <a514effa-76a6-4930-9278-f9345d3da8b0@googlegroups.com> <87bmsxs9r0.fsf@bsb.me.uk> <59c9c47f-4129-4470-aa2e-d2ff87474654@googlegroups.com> <8737e8qerw.fsf@bsb.me.uk> <f99141c0-d09f-42c3-bba5-794c682ff3a8@googlegroups.com> |
silusilusilu@gmail.com writes: >> > It is a requirement >> >> Then your simplest solution is might be to break the include files up, >> but I am puzzled by why this is a requirement. If you say a bit more >> about why this is important, you might get some better suggestions. >> Elsewhere, you comment that one of the source files might not exist. >> That suggests that your situation is not the normal one envisioned by >> build systems. > > Currently we have a unique repository with all the source code of our > project, however my boss decided to put in the repository only object > files for "sensitive" source code. > > This possibility should not block other team members to compile the > entire build and make their changes on the remaining files. I > disagree with that choice but for me it is a requirement Ah, so what you need is not so much something that avoids unneeded recompiles but something that can tell the difference between a change where the old .o file could safely be used and a change where that would actually build an incorrect program. You could live with an unnecessary recompile, provided you could tell when the error can be safely ignored. And where you do have all the source, the occasional extra compile is, again, not really the problem. >> You can't always get finer compile granularity just by splitting the >> include files up because, sometimes, it comes down to what #defines are >> in play. It's possible that some quite complex use of scons could >> accommodate this situation but I am not really familiar with it. > > I don't know how scons can be used to avoid a compilation problem like > this one. (but i don't know scons very well) SCons appears to be entirely programmable so, one way or another, there would be a way to implement almost any conceivable policy. It might take more effort than persuading your boss that not breaking the build system is a better option, but it can probably be done. -- Ben.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Linker question silusilusilu@gmail.com - 2017-03-19 04:42 -0700
Re: Linker question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-19 05:10 -0700
Re: Linker question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 12:59 +0000
Re: Linker question silusilusilu@gmail.com - 2017-03-20 04:06 -0700
Re: Linker question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-20 13:05 +0000
Re: Linker question silusilusilu@gmail.com - 2017-03-20 06:24 -0700
Re: Linker question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-20 13:51 +0000
Re: Linker question Manfred <noname@invalid.add> - 2017-03-20 16:03 +0100
Re: Linker question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-20 17:09 +0000
Re: Linker question gof@somewhere.invalid (Adam Wysocki) - 2017-03-20 09:59 +0000
Re: Linker question silusilusilu@gmail.com - 2017-03-20 04:13 -0700
Re: Linker question gof@somewhere.invalid (Adam Wysocki) - 2017-03-21 09:44 +0000
csiph-web