incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nazmul Alam <>
Subject Re: [HELP] compiling source in VSC++
Date Fri, 20 Jul 2012 10:17:39 GMT
Thanks Andre for your detailed explanation.

Should I try with eclipse + cygwin in windows?
On Jul 20, 2012 1:32 PM, "Andre Fischer" <> wrote:

> 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/
> 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/ 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 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_**<>
> )
>   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.
> 3. dmake modules
> 4. build modules
> 5.
> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message