Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #106570

Re: Linker question

Show all headers | View raw

On 3/20/2017 2:51 PM, Ben Bacarisse wrote:
> 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.

Doesn't the requirement sound like handling the "sensitive" modules as a 
closed-source library?
Such modules could in fact even be packed in a static library, IIUC.
This way of handling would require the usual for libraries:
A clear identification of the modules (library) interfaces, i.e. header 
files that declare all and only the functions (APIs) defined in the 
modules, and prototype declarations of callback functions (if any) used 
by the modules.
(plus obviously managing symbol uniqueness, global data objects etc..)
Did *I* miss the point?

>
> 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.
>

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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