On Sun, 11 Nov 2012 19:13:04 +0800 JonY <[email protected]> wrote:
> On 11/11/2012 18:50, Pau Garcia i Quiles wrote: > > On Sun, Nov 11, 2012 at 11:27 AM, JonY <[email protected]> wrote: > > > >>> What were the "rigidities"? Maybe I can help > >> > >> We need to a way to inject .a libraries with additional objects compiled > >> from a different step, > > > > See add_library(OBJECT): > > > > http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library > > > > (in the past you needed to list all the source files again -the > > recommendation was to use a variable- and they would get compiled > > again, with the new -potentitally diferent- cflags) > > > > Close, but not yet. > > "Object libraries may contain only sources (and headers) that compile to > object files. They may contain custom commands generating such sources, > but not PRE_BUILD, PRE_LINK, or POST_BUILD commands. Object libraries > cannot be imported, exported, installed, or linked." In the mruby project, the single file mruby executable contains both C library code and ruby script libraries (compiled into C) that's all linked together into a static lib. I use an object library to hold the C library code and bison output https://github.com/mruby/mruby/blob/master/src/CMakeLists.txt#L9 and add to the object library to create the final static lib https://github.com/mruby/mruby/blob/master/mrblib/CMakeLists.txt#L48-53 used to build the final single file mruby executable https://github.com/mruby/mruby/blob/master/tools/mruby/CMakeLists.txt#L3-5 But that usage doesn't address your concerns listed below. Moving on... > >> and a generic way to differentiate lib32/ and > >> lib64/ def file for differing processing arguments. > > > > I'm not sure I understand. > > > > Do you mean finding out whether you are on 32-bit or 64-bit and > > generating a different .def depending on that? Or taking a different > > .def file when you are compiling depending on whether you are on > > 32-bit or 64-bit and/or generating (maybe cross-compiling) for 32-bit > > or 64-bit? > > > > Whatever it is, there is a way to determine it. Or maybe I am missing > > what you mean? > > > > Pass different arguments to process them depending if they are from > lib32 or lib64. Of course, this should be done before the Object_Library > step. > > Some of the .c sources need to be compiled twice with different CFLAGS > and injected into their respective libraries. I don't have to do this for mruby, but I think what I do to use mruby's custom tools when cross-compiling could handle this scenario. I'm hoping Pau Garcia i Quiles will weigh in here. First, some background. mruby has part of its standard library as ruby scripts which need to be combined with the C-based portions of its standard library into a final single-file exe. These ruby scripts are "compiled" to a temp C file by the `mrbc` tool which uses the object library mentioned above. https://github.com/mruby/mruby/blob/master/tools/mrbc/CMakeLists.txt#L3-7 I also had to build a simple cross-platform `xpcat` tool (as we know Windows users don't have `cat` and we don't want to force them to find a port and futz with PATH) used to combine the ruby scripts into a single file compiled by `mrbc` into a C file. https://github.com/mruby/mruby/blob/master/tools/xpcat/xpcat.c When you're cross-compiling, these internal helper tools must be built and run on the build platform in order to create the cross build. All this must be done before you create the final static lib that uses the object library. https://github.com/mruby/mruby/blob/master/mrblib/CMakeLists.txt#L3-45 So here's the question. Can the method I use when cross-compiling, namely, use cmake's `ExternalProject` module (causes cmake to run itself and generate artifacts in a different dir) to pre-build an environment on the build system that's used by the cross build https://github.com/mruby/mruby/blob/master/mrblib/CMakeLists.txt#L7-14 address JonY's need to be able to build multiple flavors of cmake object libraries, carry them around, and inject them into their respective static libraries? I don't know as I haven't investigated. Jon ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
