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

Groups > comp.compilers > #548 > unrolled thread

combining c-code files into one c-code file

Back to article view | Back to comp.compilers

Contents

  combining c-code files into one c-code file Harald Gustafsson <harald.gustafsson@gmail.com> - 2012-04-03 06:23 -0700
    Re: combining c-code files into one c-code file Cameron McInally <cameron.mcinally@nyu.edu> - 2012-04-04 12:02 -0400
    Re: combining c-code files into one c-code file Harald Gustafsson <harald.gustafsson@gmail.com> - 2012-04-04 19:35 +0200
    Re: combining c-code files into one c-code file Gene <gene.ressler@gmail.com> - 2012-04-09 05:40 -0700
    Re: combining c-code files into one c-code file Harald Gustafsson <harald.gustafsson@gmail.com> - 2012-04-18 02:01 -0700

#548 — combining c-code files into one c-code file

I'm trying to convert libx264 to Android's renderscript as an exercise in how
much work it is to port a bit larger project into renderscript. One of the
pains with renderscript is that the complete executable needs to be declared
within the same file scope (can't easily access functions or constants in
other files) and functions and global variables needs to be declared static to
not automatically get a java interface. Renderscript is C99 compliant.

I started to just include all the c-code files into one renderscript-file and
compile that. Which would had worked quite easily if not libx264 itself had
also included c-files with different pre-processing macro definitions, hence
some functions exist twice with different content and some are redeclared
identical. I could of course handle this manually with many days of work, but
it would be easier with a tool.

I'm asking if anyone knows of a tool that can take a list of c-files and
pre-process/merge that into one c-file, managing redeclarations, conflicting
declarations, declaration order, etc. The readability of the output is less
important but prefers as human readable as possible.

An alternative is to have one file scope but separate each included c-file
into its own namespace, does C99 have any such support?

Regards,
  Harald

[toc] | [next] | [standalone]

#549

Hey Harald,

No, I do not know of any tool that will do such things automatically.
But, a tool like this is not something that would be on my radar.

I do have a small bit to add though, which may make such a tool a tall
order. One immediate issue I see is determining linkage of symbols
when consolidating the source. When handling WEAK symbols, the link
line (and potentially the characteristics of your linker), will play a
role in determining which definition should be selected for each
reference. Whether you intend to link your program statically or
dynamically muddles the issue further.

At the very least, if your program is reasonably complex, this tool
you seek would need to have knowledge about the linker that you're
using on your system.

Hope that helps!,
Cameron

On Tue, Apr 3, 2012 at 9:23 AM, Harald Gustafsson
<harald.gustafsson@gmail.com> wrote:

> pre-process/merge that into one c-file, managing redeclarations, conflicting
> declarations, declaration order, etc. The readability of the output is less
> important but prefers as human readable as possible.
>
> An alternative is to have one file scope but separate each included c-file
> into its own namespace, does C99 have any such support?

[toc] | [prev] | [next] | [standalone]

#550

Hi Cameron,

From what I could find so far the project I'm porting does not use weak
symbols, but if such was used then the linking is important if several
identical symbols exist. Everything needs to be "linked" statically since it
is going to be one file scope, the code I'm converting is one static library.

So far I have found two tools that seems to be a good start. The CScout
commercial tool, the author has said that all the parts are in the tool, and
it could be adapted to also output the complete file scope. This tool handles
large projects like the Linux kernel (which I think use weak symbols), but I
have not yet verified the correctness of the tool for my libx264 porting. Then
I also discovered that a colleague five rooms from me had made such a tool 10
years ago, it basically uses gcc preprocessor then implements a c-parser and
rename clashing identifiers and prints them in one file. The purpose was to
investigate if the compiler could do a better job when getting one large file
scope instead of several. This tool is not as advanced and foolproof as CScout
but it has been tested on projects like audio codecs and protocol stacks. It
would likely not handle weak symbols, at least not by design.

/Harald

On 4 apr 2012, at 18.02, Cameron McInally wrote:

> Hey Harald,
>
> No, I do not know of any tool that will do such things automatically.
> But, a tool like this is not something that would be on my radar.
>
> I do have a small bit to add though, which may make such a tool a tall
> order. One immediate issue I see is determining linkage of symbols
> when consolidating the source. When handling WEAK symbols, ...

[toc] | [prev] | [next] | [standalone]

#552

On Apr 3, 9:23 am, Harald Gustafsson <harald.gustafs...@gmail.com>
wrote:
> I'm asking if anyone knows of a tool that can take a list of c-files and
> pre-process/merge that into one c-file, managing redeclarations, conflicting
> declarations, declaration order, etc. The readability of the output is less
> important but prefers as human readable as possible.

I don't know a tool, but I've done this (for a completely different
reason) with a moderately complex program. Conflicting preprocessor
definitions were the main problem as for you. We ended up writing a
script to have gcc dump preprocessor definitions (there is a command
line flag for this), converting them to "undefs".  This was run on
each source file to effectively create a cpp table cleanup that we
could include after each source file.  So the master file looked like

#include "foo.c"
#include "foo.undefs.c"
#include "hoo.c"
#include "hoo.undefs.c"
...

This isn't sufficient for all programs (e.g. the weak symbol case
already mentioned).  E.g. there ware cases where static declarations
conflicted and it was necessary to modify the static name locally with
#define #undef .

...
#define conflicting_static_name BAR_conflicting_static_name
#include "bar.c"
#include "bar.undefs.c"
#undef conflicting_static_name
...

[toc] | [prev] | [next] | [standalone]

#563

Just wanted to inform you that I got another off-list tip based on my question
on this list to use CIL from Berkley.
http://sourceforge.net/projects/cil/

It has a merge function that works great, just redefining CC, LD and AR in
makefile. I also managed with the CIL-lists help to make a visitor to make all
global declarations static which I needed for Renderscript. So far I have
managed to merge the libc string operations and a malloc implementation, as
well as making libx264 compile inside renderscript (have not had a chance to
test it yet).

Thanks,
Harald

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compilers

csiph-web