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

Groups > comp.lang.c > #106592

Re: Linker question

Show all headers | View raw

Manfred <noname@invalid.add> writes:

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

No, I think you have described one of the suggestions I made but from
"the other side".  When I talked about splitting up the include files so
that only the parts that actually relate to the (what I now know are
hidden) source files that should not be re-compiled, I was, rather
clumsily, suggesting that a fixed API be defined for those files.

Your way of putting it -- thinking of them as a closed-source library
with a fixed API -- is clearer though it may not map naturally onto the
actual situation in hand.  That does not mean it's not worth using it.
If the code can be reorganised to make that separation clear, it may
improve the structure overall.

<snip>
-- 
Ben.

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