incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre Fischer ...@a-w-f.de>
Subject Re: [HELP] compiling source in VSC++
Date Fri, 20 Jul 2012 07:32:17 GMT
Hi Nazmul,

On 19.07.2012 17:51, Nazmul Alam wrote:
> Can anybody give some direction on compiling source on VSC++ ?
> I know it can be done in cygwin. But I would like to try the native build.
> Also This would help a lot in my development engagement.

I am sorry, but that is not possible.

>
> I tried to perform the build incrementally by following Makefile. But it
> seems it invokes python build script or application to build the whole
> application. I don't know anything about python. Can anyone give me some
> idea on building the AOO in incremental steps?

I am not sure that that is what you asked for but here is an overview 
over the whole build procedure:

- configure
   This is done mostly by the automake/autoconf tools.  First the 
main/configure.in template is   translated into main/configure.  This is 
called with several switches that allow you to tune
   what is and what is not built.  Here you also specify where your MSVC 
C/C++ compilers live,
   which are used on Windows to do the actual compilation.
   The bootstrap script will then download missing third-party source 
tarballs and extensions.

- build
   main/solenv/bin/build.pl is the main Perl build script.  Call it in 
main/instsetoo_native like this
       build --all
   and it will trigger everything else: building all relevant modules
   (subdirectories in main/, ext_libraries/, and extras/) and the
   creation of installation sets. For building the modules there are
   two different systems:
   = dmake
     This is a collection of makefiles for dmake that live in
   main/solenv/inc.
     Modules that are build with dmake files write their output (eg object
   files and libraries) to a module local output tree (wntmsci12/ on
   windows, unxlngi6 on Linux 32bit, etc)
   = gbuild
     A new approach that uses GNU make to eventually allow a global
   makefile instead of build.pl and global dependencies between files
   of different modules.  Today dependencies are restricted to single
   modules.  With global dependencies you could change a file in
   main/vcl, then call build --all in instsetoo_native/ and everything
   that dependes on the modified file would be built.
     Modules that are build with gbuild write their output to a global
   output tree: main/solver/<version>/<platform>/workdir

   Both have a final deliver step that writes output files that are
   used by other modules (instsetoo_native/ being the most important
   one of these, it needs access to everything that is included in
   installation sets) to a global output tree, the so called solver:
   main/solver/<version>/<platform>.  For dmake modules you have to
   call the deliver command explicitly, for gbuild modules that is done
   automatically.


- creating the installation set
   This is done by a Perl script (main/solenv/bin/make_installer.pl)
   that consists of quite a few Perl modules all of which are located
   in main/solenv/bin/modules/installer.
   With the help of the *.scp files in module main/scp2/ it gathers the
   set of files that are to be included in the installation set.
   Usually more than one installation set is built, one in archive form
   (just unzip or untar it and run it, no further installation
   necessary) and one that can be installed on the platform of your
   choice via the usual way (msi on windows, rpm and/or deb packages on
   Linux, etc).  When the --with-lang switch was given to configure
   then on installation set is built per language.


As you see, there are five different parts in the AOO build system:
1. configure
2. build.pl
3. dmake modules
4. build modules
5. make_installer.pl

A Visual Studio solution would have to do everything that is done in
these five steps.  It would be great to have such a solution, it would
certainly speed up building on Windows, but I am afraid that this lies
in the very distant future.

Best regards,

Andre

Mime
View raw message