Am Fri, 19 Mar 2010 17:09:50 +0100
schrieb Thorsten Behrens t...@openoffice.org:
too long a silence around this important topic for my taste
You know: If the kids are quiet, something is up ... ;)
Mba and I continued to work/evaluate on cmake and GNU/make. I did work
mostly on windows and it
Hi,
too long a silence around this important topic for my taste - so let
me tease you folks with this here new kid on the block:
http://aruiz.synaptia.net/siliconisland/2010/03/buildj-build-configuration-for-the-mases.html
;)
Cheers,
-- Thorsten
pgp1VOCzhBbNV.pgp
Description: PGP signature
Jussi Pakkanen wrote:
On Thu, Feb 11, 2010 at 2:01 PM, Martin Hollmichel
martin.hollmic...@sun.com wrote:
one problem right now is that the usage of linker mapfiles (e.g.
sal/util/sal.map) are not straight supported by cmake, unfortunately all
the
creation of several win32 import libraries
On Wed, Feb 17, 2010 at 11:57 AM, Martin Hollmichel
martin.hollmic...@sun.com wrote:
usually I analyse the build logs for understanding these kind of mechanisms,
here's my extract for sal module on Linux:
...
tr -d \015 sal.map | awk -f ./solenv/bin/addsym.awk
Jussi Pakkanen wrote:
On Wed, Feb 17, 2010 at 11:57 AM, Martin Hollmichel
martin.hollmic...@sun.com wrote:
usually I analyse the build logs for understanding these kind of mechanisms,
here's my extract for sal module on Linux:
...
tr -d \015 sal.map | awk -f ./solenv/bin/addsym.awk
On Wed, Feb 10, 2010 at 9:00 PM, Martin Hollmichel
martin.hollmic...@sun.com wrote:
yes, thank you, I used and modified some of your work (add_idl_db and
build_rdb_from db functions) and added a more modules (up to rsc now).
A word of warning: the functions I have written to deal with
Jussi Pakkanen wrote:
On Wed, Feb 10, 2010 at 9:00 PM, Martin Hollmichel
martin.hollmic...@sun.com wrote:
yes, thank you, I used and modified some of your work (add_idl_db and
build_rdb_from db functions) and added a more modules (up to rsc now).
A word of warning: the functions I
Martin Hollmichel wrote:
There's also the dmake
- cmake converter script so you don't have to keep writing the files
by hand.
from what I've learned from cmake so far, it seems the best idea to do
an 1:1 conversion since this might lead to too much targets (and thus
dependencies) and
Jussi Pakkanen wrote:
On Mon, Jan 11, 2010 at 8:11 PM, Martin Hollmichel
martin.hollmic...@sun.com wrote:
I started some time ago a cmake prototype for OOo in my spare time
(http://hg.services.openoffice.org/hg/cws/mh6bc/) for the latest status
please see the latest ReadMe.txt in the Source
On Wed, 27 Jan 2010 13:57:22 +0200
Jussi Pakkanen jpakk...@gmail.com wrote:
I think I see your concern now. When CMake does the library
resolvation part it does it itself (i.e. not with Make) and this is
always done with a single process and looking at the global state. The
makefiles it
Jussi Pakkanen wrote:
BTW, what does the GNU Make solution use for platform configuration?
Autoconf? Some in-house tool?
We didn't want to change that - so far it's planned to be the same stuff
as today (calling our configure script).
Of course, TANSTAAFL: I'm sure we will be the first to
On 01/27/10 09:07, Mathias Bauer wrote:
Jussi Pakkanen wrote:
Yes, sure. If and only if you have target_link_libraries(some_exe
some_library) then the linker invocation for some_exe will have
'-lsome_library'. Whether or not it was built accidentally, CMake will
not link the exe against the
On Wed, Jan 27, 2010 at 10:07 AM, Mathias Bauer mathias.ba...@sun.com wrote:
The parallelization comes from the build.pl. Let's go back to our simple
example with the 4 libraries/modules. When build.pl is called to build
D, it discovers it has to build B and C before (as the build.lst of D
Stephan Bergmann wrote:
On 01/27/10 09:07, Mathias Bauer wrote:
Jussi Pakkanen wrote:
Yes, sure. If and only if you have target_link_libraries(some_exe
some_library) then the linker invocation for some_exe will have
'-lsome_library'. Whether or not it was built accidentally, CMake will
not
Hi Jussi,
before we continue let me add some words to avoid misunderstandings. In
no way I'm trying to cast a bad light on CMake or want to defend our
trial approach just because. But before I consider to support a
different approach I want to get the essential problems discussed in the
same
Jussi Pakkanen wrote:
On Wed, Jan 13, 2010 at 5:21 PM, bjoern michaelsen - Sun Microsystems
- Hamburg Germany bjoern.michael...@sun.com wrote:
Mu. As long as you have a recursive build process, you have a lot of
implicit dependencies and those are hurting parallelization. On top of
that,
On Thu, Jan 21, 2010 at 10:50 AM, Mathias Bauer mathias.ba...@sun.com wrote:
So, how can we implement include, not execute with CMake?
You can do this, if it is absolutely necessary. I'll describe that at
the end of the message.
Consider that you have the modules A, B, C and D. D depends on B
Jussi Pakkanen wrote:
On Mon, Jan 11, 2010 at 7:57 PM, Thorsten Behrens t...@openoffice.org wrote:
functionality? Even if CMake eventually turns out to be too slow,
would it not make more sense to write your own custom CMake back
end rather than the configuration/generation front end?
I
Thorsten Behrens wrote:
bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote:
But the actual information contained in the above lines is actually
this:
rscdep source files: tools/bootstrp/*
rscdep link libs: tl
Quoting a band from Hamburg: Jein (=Yes and No).
Of course,
Thorsten Behrens wrote:
Given that the syntax of the build task description language should
be simple (because, if one needs it to be complex, one is likely Doing
It Wrong(tm)) I wonder, if something that can be processed by the
POSIX-shell or the C-Preprocessor would not be possible too(*).
Mathias Bauer wrote:
Jussi Pakkanen wrote:
On Mon, Jan 11, 2010 at 7:57 PM, Thorsten Behrens t...@openoffice.org wrote:
functionality? Even if CMake eventually turns out to be too slow,
would it not make more sense to write your own custom CMake back
end rather than the
On Wed, 13 Jan 2010 15:12:40 +0100
Martin Hollmichel martin.hollmic...@sun.com wrote:
Mathias Bauer wrote:
So the only way to reuse CMake makefiles for a complete build is
recursively calling them or - as we do today in OOo - serialize the
process. I don't think that this is a matter of
On Wed, Jan 13, 2010 at 5:21 PM, bjoern michaelsen - Sun Microsystems
- Hamburg Germany bjoern.michael...@sun.com wrote:
Mu. As long as you have a recursive build process, you have a lot of
implicit dependencies and those are hurting parallelization. On top of
that, process instantiation and
On 01/11/10 23:44, bjoern michaelsen - Sun Microsystems - Hamburg
Germany wrote:
Am Mon, 11 Jan 2010 18:04:21 +0100
schrieb Stephan Bergmann stephan.bergm...@sun.com:
Which, at least in its simplest form, would imply that it necessarily
modifies the source tree by adding files to it, something
bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote:
But the actual information contained in the above lines is actually
this:
rscdep source files: tools/bootstrp/*
rscdep link libs: tl
Quoting a band from Hamburg: Jein (=Yes and No).
Of course, there is a lot of
On Mon, 11 Jan 2010 16:05:57 +0200
Jussi Pakkanen jpakk...@gmail.com wrote:
I would like to point out that what you are doing is generating your
own language and a build tool/generator based on that. There's nothing
wrong with it as such, but this is reinventing the wheel again (just
like
On Tue, Jan 12, 2010 at 12:35 PM, bjoern michaelsen - Sun Microsystems
- Hamburg Germany bjoern.michael...@sun.com wrote:
What is the benefit you get from this instead of using something like
CMake that already has a mature implementation of this functionality?
One dependency less (because
On Tue, 12 Jan 2010 17:37:59 +0200
Jussi Pakkanen jpakk...@gmail.com wrote:
On Tue, Jan 12, 2010 at 12:35 PM, bjoern michaelsen - Sun Microsystems
- Hamburg Germany bjoern.michael...@sun.com wrote:
One dependency less (because you will need an additional native
build system like GNU make or
On Mon, Jan 11, 2010 at 3:07 PM, Thorsten Behrens t...@openoffice.org wrote:
I think it's cleaner, and there's definitely not much (should I say
any?) redundancy left. Additionally, one can enhance the script to
generate makefiles for pretty much every make tool of this world,
including
On 01/11/10 14:07, Thorsten Behrens wrote:
So I hacked up some python to parse a sort of declarative input
file, and generate gnu makefiles with Björn's eval framework out of
that.
At what stage of the development/build process would that script be called?
-Stephan
Stephan Bergmann wrote:
So I hacked up some python to parse a sort of declarative input
file, and generate gnu makefiles with Björn's eval framework out of
that.
At what stage of the development/build process would that script be called?
I'd personally use it to dynamically generate the
On 01/11/10 17:48, Thorsten Behrens wrote:
Stephan Bergmann wrote:
So I hacked up some python to parse a sort of declarative input
file, and generate gnu makefiles with Björn's eval framework out of
that.
At what stage of the development/build process would that script be called?
I'd
Hi,
I think it's cleaner, and there's definitely not much (should I say
any?) redundancy left. Additionally, one can enhance the script to
generate makefiles for pretty much every make tool of this world,
including eclipse/netbeans/visual studio project files.
I would like to point out
On Mon, Jan 11, 2010 at 8:11 PM, Martin Hollmichel
martin.hollmic...@sun.com wrote:
I started some time ago a cmake prototype for OOo in my spare time
(http://hg.services.openoffice.org/hg/cws/mh6bc/) for the latest status
please see the latest ReadMe.txt in the Source root for the most recent
On Mon, Jan 11, 2010 at 7:57 PM, Thorsten Behrens t...@openoffice.org wrote:
functionality? Even if CMake eventually turns out to be too slow,
would it not make more sense to write your own custom CMake back
end rather than the configuration/generation front end?
I guess it's now my turn to
Am Mon, 11 Jan 2010 17:48:18 +0100
schrieb Thorsten Behrens t...@openoffice.org:
I'd personally use it to dynamically generate the makefiles (i.e.
from configure, or triggered from a smallish global makefile).
With GNU make there would not be a need for an extra makefile. You can
include
Am Mon, 11 Jan 2010 18:04:21 +0100
schrieb Stephan Bergmann stephan.bergm...@sun.com:
Which, at least in its simplest form, would imply that it necessarily
modifies the source tree by adding files to it, something I
personally would prefer moving away from.
No. Generated makefiles are
Hi Björn,
On Monday 07 of December 2009, Björn Michaelsen wrote:
Additionally, and since you mentioned the desire to have only one
make instance - last time someone tried to have gnu make hold all of
OOo's dependency tree in one process, that guy (Kai Backman) ended
up with absolutely
On Mon, 07 Dec 2009 11:17:30 +0100
Jan Holesovsky ke...@suse.cz wrote:
Any chance to profile GNU make in this scenario, please? May be
there is some stupid mistake there, similar to the one in mkdepend
(http://www.openoffice.org/issues/show_bug.cgi?id=73081 - the
complexity of it grew
Hi Mathias,
most of the points you've raised I already replied to in my followup
to Bjoern (including my ideal msword lib makefile) -
Mathias Bauer wrote:
build.pl uses module dependencies, not target dependencies, so it has an
inherent susceptibility to bottlenecks. Basically all of our c++
Thorsten Behrens wrote:
No, really, there's nothing nailed until now. If you or anybody else
knew a better way and(!) offered help and cooperation, there's nothing
that would hold us back from doing it differently.
I find this and(!) slightly worrying - not that I would not lend a
helping
On Mon, 07 Dec 2009 11:01:02 +0100
Thorsten Behrens t...@openoffice.org wrote:
This is a circular argument. Correct dependencies and the underlying
build/make system used are orthogonal. As an aside, I guess I'm only
questioning the rationale here, not the goal - getting rid of the
build.pl
bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote:
# loads cxxflags, weird sw include setup etc.
include sw_defaults
Here you will either need to use dirty tricks or you will clash in a
global namespace, because you would like these defaults to be applied
to msword and others
On Mon, 07 Dec 2009 13:46:19 +0100
Thorsten Behrens t...@openoffice.org wrote:
That's exactly why I wonder if we should have a level of abstraction
above naked gnu makefiles - i.e. a DSL that gets translated into
makefiles.
Actually, the files describing the actual stuff to build are a kind
Thorsten Behrens wrote:
Hi Mathias,
most of the points you've raised I already replied to in my followup
to Bjoern (including my ideal msword lib makefile) -
Mathias Bauer wrote:
build.pl uses module dependencies, not target dependencies, so it has an
inherent susceptibility to
Hi Thorsten,
Björns approach is the first one in the last 10 years I can see has
potential, to simplify the build, to improve scalability, to improve
dependencies, to improve build performance, to align our makefiles, to
reduce code.
A build system, in particular one based on (GNU) make, is
Mathias Bauer wrote:
So if you could explain how bjam (or any other make system that
someone wants to suggest here) solves our problems or why the
problems that require bjam to be resolved are even bigger than
those we try to fix, we might be able to get somewhere.
I did that, if you
Thorsten Behrens wrote:
Mathias Bauer wrote:
So if you could explain how bjam (or any other make system that
someone wants to suggest here) solves our problems or why the
problems that require bjam to be resolved are even bigger than
those we try to fix, we might be able to get somewhere.
On 04/12/2009 18:41, Thorsten Behrens wrote:
Hi Bjoern, *,
In line with that, why not using autotools? It's ugly, it has many
drawbacks, but it's _the_ standard for FLOSS. Plus, it has excellent
cross-build capabilities, something I consider increasingly
important.
well, we already use
49 matches
Mail list logo
