On 19.04.2013 10:02, janI wrote:
On 19 April 2013 07:56, Jürgen Schmidt <[email protected]> wrote:
On 4/19/13 12:33 AM, Kay Schenk wrote:
On Thu, Apr 18, 2013 at 2:11 PM, janI <[email protected]> wrote:
On 18 April 2013 22:38, Kay Schenk <[email protected]> wrote:
On Thu, Apr 18, 2013 at 5:17 AM, janI <[email protected]> wrote:
On 18 April 2013 14:08, Claudio Filho <[email protected]> wrote:
Hi
2013/4/18 Oliver-Rainer Wittmann <[email protected]>:
But regarding the removed Slot FN_PROPERTY_WRAP_DLG perform a clean
build of
module sw:
- cd sw
- make clean
- build
Oliver, sorry by my newbie ask, but... we don't use more dmake?
If i understood correctly, "build" is a perl script that calls all
modules, building in order of dependence, entering in each one,
calling Dmake to compile and delivering all files where need.
correct.
I saw some "makefile" files and many more "makefile.mk", where i
think
that one is for Make and other is to Dmake. I see it in wiki too, for
build parts.
again correct.
Problem is that some of the modules have been moved away from dmake to
"gbuild", so right now it is a mix (and not a very smart one).
Jan --
This last comment "not a very smart one" is interesting. Do you care to
elaborate?
I have to watch more carefully what I write, someone is actually
reading it
:-)
yes, we do that sometimes! :)
I am deep in the building system at the moment with my l10n work, and
what
we have now in trunk is approx 2/3 orignal dmake (that btw also seem to
have at least 2 generations) and 1/3 gbuild, this combination does a
good
job of confusing anyone who tries to understand the system. Just to make
things worse, the gbuild part is split in as many files as possible.
So I should have written "dont try to understand it, just accept it",
actually someone else in here said something similar to me a couple of
month ago.
Exactly that is the problem, the work on gbuild is not yet finished and
we have a mix of gnu make and dmake. The gbuild is the outcome of an
analysis how to improve the build system. I believe it is not bad and
our friends from LO have more or less finished the work but I also
believe that it is too complex and can be done much simpler.
It's nearly impossible to debug and not easy to understand. It tried to
hide the complexity from single makefiles in the modules and introduced
soe kind of new scripting language based on gnu make. I am not sure if
that was the best approach.
As I wrote earlier, the gbuild team have done a fantastic job analyzing our
system.
I am sure there is something wrong the approach, when you have a chain of 5
makefiles (one include the other)...so to me the structure itself is very
complex.
I personally think this improves what little readability gbuild has. If
you know that you want to fix a bug when building a library then you
just have to look at LinkTarget.mk (the 'base class') or Library.mk
(derived class with code that does not apply to static libraries). For
platform specific things you look at platform/<platform>.mk. I would
even think about splitting up AllLangResTarget.mk into files for
SrsPartMergeTarget, SrsPartTarget, SrsTarget, ResTarget, and
AllLangResTarget (one 'class' per file, like in Java).
I don't know if having all this in a single makefile would improve
maintainability of gbuild.
There is a reason both for the scripting language and the complex
structure. Both dmake and gbuild tries to solve the whole world and cook
coffee at the same time.
What I mean is, there are no separation between a couple of logical steps:
- Clean/create directories and other items needed for the actual make. This
happens on the go and everytime you build. In my world we should have a
"make prepare" that I call ONCE after svn co, and the real build should
assume all directories are present.
Maybe we have to distinguish between (hm, how do I put this into english
words?) information or knowledge on one hand and process or running
actual commands on the other hand. The information in case of "make
clean" is that eg compiling a file <name>.cxx produces a file
<name>.obj. The important part is that <name>.obj is an automatically
created file that can be re-created at any time. So, the 'clean' target
depends on <name>.obj but not on <name>.cxx. The action in this example
is that all dependencies of the 'clean' target are deleted.
The separation between these two exists in gbuild but is not absolute.
Much of the action, the so called commands, are defined in the
solenv/platform/<platform>.mk files while the information, mostly the
dependencies between files, are defined in solenv/*.mk. But you are
right, that some of the simpler actions, like deleting files for 'make
clean' or the creation of directories before eg compiling files into
them, is not cleanly separated.
I don't know how a "make prepare" could work without defining
dependencies between files (and directories) in two places. And I
really mean that I don't know, not that I think that this is a bad idea.
- Intermodule dependencies. Every module checks at every build if the
modules it depends has been built. In my world, module makefile should only
do the module, and a makefile in main takes care of the interdependencies.
That would reintroduce (or not fix) several problems:
- Inter-module dependencies as we have them today have to be specified
manually. That is error-prone as is demonstrated by some of the build
bot problems. In contrast Inter-file dependencies can be extracted
automatically from header files. I think that every compiler that we
use can do that.
- When the build system detects that one file in module A has been
modified and as consequence module B has to be built because B depends
on A, then every file in A and every file in B has to be built. In
reality this is hardly ever necessary. I don't know if there are files
that with inter-file dependencies would cause this worst case.
- At the moment a developer has to know whether a change he or she makes
is incompatible, ie requires files in other modules to be re-built.
This is sometimes hard to find out and, just to be on the safe side, you
have to start an incompatible/clean build. With inter-file
dependencies, the build system knows what has to be rebuild and rebuilds
only the affected files.
But of course there are drawbacks. One is the increased amount of
dependencies that have to be created, read with every build, and
checked. This certainly takes more time than to resolve inter-module
dependencies. Especially when you build the whole office, eg after a
fresh checkout from SVN, then inter-module dependencies are probably a
bit faster. But if you change one or just a small number of files (a
typical use case in the life of an AOO developer) and there are
(potential) incompatible changes then I would always prefer inter-file
dependencies.
One example from my current work. I am currently fixing bugs in the
sidebar. Its implementation is located in sfx2, svx, sw, sc, sd with
configuration files in officecfg. If I make an incompatible change in
sfx2/source/sidebar then only sidebare related files in svx, sw, sc and
sd are affected. Should be done in a couple of minutes. But with our
current inter-module dependencies I have to do a full clean build from
sfx2. That takes about one hour.
I have tried the LO gbuild, and it is not particulary fast either.
Interesting. Did you do a full build or changed only a few files?
Regards,
Andre
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
