Skip to Content.
Sympa Menu

charm - Re: [charm] Build with ninja

charm AT lists.cs.illinois.edu

Subject: Charm++ parallel programming system

List archive

Re: [charm] Build with ninja


Chronological Thread 
  • From: Jozsef Bakosi <jbakosi AT gmail.com>
  • To: Phil Miller <mille121 AT illinois.edu>
  • Cc: "charm AT cs.uiuc.edu" <charm AT cs.uiuc.edu>
  • Subject: Re: [charm] Build with ninja
  • Date: Mon, 14 Jul 2014 09:56:07 -0600
  • List-archive: <http://lists.cs.uiuc.edu/pipermail/charm/>
  • List-id: CHARM parallel programming system <charm.cs.uiuc.edu>

So here is how I'm able to use ninja with Charm++ now:

As you suggested, I use the naked compiler to generate the intermediate objects and I only use the charmc wrapper for the final link step for the executable. Here is the relevant cmake code that instructs cmake to exchange the linker for charmc only for the final executable:

# Link Charm++ executable with the charmc wrapper
STRING(REGEX REPLACE "<CMAKE_CXX_COMPILER>" ${CHARM_COMPILER} CMAKE_CXX_LINK_EXECUTABLE "${CMAKE_CXX_LINK_EXECUTABLE}")

The above line does a string substitution on the linker command line and replaces the template, "<CMAKE_CXX_COMPILER>", by the value of the cmake variable CHARM_COMPILER, which should be set to the charmc wrapper.

Jozsef

On Sun, May 4, 2014 at 4:05 PM, Phil Miller <mille121 AT illinois.edu> wrote:
So, looking up those flags in the g++ man page, that command line is not actually aiming to compile test.C at all - it's trying to generate dependencies for its compilation.

charmc's support for this usage is non-existent. Those flags require rather special behavior from anything wrapping the compiler and interpreting other flags, beyond just adding include paths and passing everything through to the backend compiler driver. It would probably take me a couple hours of reading dense manuals to even estimate the effort it would take to properly support these.

In the cases I know of where we do dependency generation for our code (the Charm++ runtime itself and the OpenAtom application), we call g++ directly.

You might want to look at the Makefile used in NAMD. They simply use g++ or whatever other native compiler for object compilation steps, and only invoke charmc for the final linking step. Since ninja's documentation describes using some external tool to generate ninja's input files, generating these rules appropriately should hopefully not be too challenging. At a first pass, it looks like the only 'special' argument you'll absolutely have to pass to the compiler is the path to the 'include' directory in your build of Charm++.

If you go this route, I'd be interested to see what you put together.

Phil




On Sat, May 3, 2014 at 8:47 PM, Jozsef Bakosi <jbakosi AT gmail.com> wrote:
Hi folks,

I'm trying to compile a Charm++ program using the ninja build system (instead of make) and I'm running into errors with the charmc script. Here is a shortened example compile line ninja generates:

$ charmc -MMD -MT test.C.o -MF test.C.o.d -o test.C.o -c test.C
Fatal Error by charmc in directory ...
   test.C.o: file not recognized: File truncated
charmc exiting...

Another one, failing due to a different argument:

$ charmc -MF test.C.o.d -o test.C.o -c test.C
Fatal Error by charmc in directory ...
   file with unrecognized extension test.C.o.d
charmc exiting...

If I take out both the "-MF test.C.o.d" and the "-MT test.C.o" options, it compiles fine. I'm not familiar with how and why ninja generates these -MT and -MF options but I assumed there is a good reason and I cannot just eliminate them.

Is there anyone else using ninja with charm?

I tried grepping for -MF and -MT in the charmc script and found no occurrences. Shouldn't the charmc wrapper script pass through any compiler option it does not recognize?

In any case, can this be fixed? That would be awesome as I prefer ninja to make.

Thank you in advance,
Jozsef

_______________________________________________
charm mailing list
charm AT cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/charm






Archive powered by MHonArc 2.6.16.

Top of Page