Re: [Error] Compile AOO on Debian amd64
I am doing all again, downloading svn, compilation, etc. Now is building Others...others errors for compile: http://pastebin.com/dKvmyfx6 Albino - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Error] Compile AOO on Debian amd64
2013/4/24 Ariel Constenla-Haile arie...@apache.org: Did you read the building guide, before trying to build? If not, please do so. I read [1]. 1 - http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO First, why are you building as root? Because, the permission with user was not allowed. Second, you should pass to configure some arguments (read the building guide, and look at the switches used to build Developer Snapshots), otherwise building might fail or you won't get a build like the ones we build for convenience. Ok. /home/albino/projetos/aoo/source/main Looks like you have changed the structure of your source checkout. If so, you should clean the whole source tree. I am starting of zero, again. Albino - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Error] Compile AOO on Debian amd64
2013/4/26 Ariel Constenla-Haile arie...@apache.org: But you are building on /home/albino, I asume you have access rights in your $HOME ;) To change ownership recursively: sudo chown -R albino:albino /home/albino/projetos (this assumes there is a group named albino, a common practice in most Linux distros). I know, tks. :-) I am doing all again, downloading svn, compilation, etc. Now is building Albino - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Error] Compile AOO on Debian amd64
Hi Continuing to try to build Others erros: http://pastebin.com/5uZmkjKi == dmake: Error: -- `/home/albino/projetos/aoo/aoo/main/solver/400/unxlngx6.pro/inc/boost/bind.hpp' not found, and can't be made 1 module(s): sal need(s) to be rebuilt Reason(s): ERROR: error 65280 occurred while making /home/albino/projetos/aoo/source/main/sal/osl/all When you have fixed the errors in that module you can resume the build by running: build --all:sal == Albino - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Error] Compile AOO on Debian amd64
On Wed, Apr 24, 2013 at 02:34:37PM -0300, Albino B Neto wrote: Hi Continuing to try to build Others erros: http://pastebin.com/5uZmkjKi Did you read the building guide, before trying to build? If not, please do so. root@tux:/home/albino/projetos/aoo/source/main# ./configure First, why are you building as root? Second, you should pass to configure some arguments (read the building guide, and look at the switches used to build Developer Snapshots), otherwise building might fail or you won't get a build like the ones we build for convenience. Concerning the error: dmake: Error: -- `/home/albino/projetos/aoo/aoo/main/solver/400/unxlngx6.pro/inc/boost/bind.hpp' not found, and can't be made There is something wrong in your setup: you are supposed to have an aoo folder inside /home/albino/projetos/aoo/ with main /home/albino/projetos/aoo/aoo/main/ but for the line where you are executing ./configure, this is not the case: /home/albino/projetos/aoo/source/main Looks like you have changed the structure of your source checkout. If so, you should clean the whole source tree. Regards -- Ariel Constenla-Haile La Plata, Argentina pgppk4Y0Gobzb.pgp Description: PGP signature
Re: Make x Dmake x Build (Was: Re: [Error] Compile AOO on Debian amd64)
On 19.04.2013 15:09, janI wrote: On 19 April 2013 14:40, Andre Fischerawf@gmail.com wrote: On 19.04.2013 10:02, janI wrote: On 19 April 2013 07:56, Jürgen Schmidtjogischm...@gmail.com wrote: On 4/19/13 12:33 AM, Kay Schenk wrote: On Thu, Apr 18, 2013 at 2:11 PM, janIj...@apache.org wrote: On 18 April 2013 22:38, Kay Schenkkay.sch...@gmail.com wrote: On Thu, Apr 18, 2013 at 5:17 AM, janIj...@apache.org wrote: On 18 April 2013 14:08, Claudio Filhofilh...@gmail.com wrote: Hi 2013/4/18 Oliver-Rainer Wittmannorwittm...@googlemail.com: 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. I am sure a single makefile would not really improve maintainability. But not going through 5 files, would speed up build time, so somewhere in between. I think that the time it takes to read the makefiles is negligible. All files under solenv/gbuild have ca 7700 lines in total. The dependency files under solver/workdir/Dep/CxxObject have ca 38000 lines. The rest of the office has a lot more. From experiments in this area I would guess that reading the 7700 lines would take around 100ms, hardly noticeable. Without going to much in detail, I see a big difference in how you specify the makefiles and what is actually running. In the project I worked with, we had configure, generate makefiles, I think aoo could benefit from that. I totally agree. I think that cmake is doing something similar. 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
Re: Make x Dmake x Build (Was: Re: [Error] Compile AOO on Debian amd64)
On 19 April 2013 07:56, Jürgen Schmidt jogischm...@gmail.com wrote: On 4/19/13 12:33 AM, Kay Schenk wrote: On Thu, Apr 18, 2013 at 2:11 PM, janI j...@apache.org wrote: On 18 April 2013 22:38, Kay Schenk kay.sch...@gmail.com wrote: On Thu, Apr 18, 2013 at 5:17 AM, janI j...@apache.org wrote: On 18 April 2013 14:08, Claudio Filho filh...@gmail.com wrote: Hi 2013/4/18 Oliver-Rainer Wittmann orwittm...@googlemail.com: 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. 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. - 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. I have tried the LO gbuild, and it is not particulary fast either. I saw all this mixture too in my build experience, and well...couldn't figure out why. It seems historically dmake was used to speed things along, but, well...I'm not sure how/why it's being used now exactly. Actually the wiki/gbuild have a pretty good description. The people who started gbuild did a real good job of analyzing the dmake build and an even better job of documenting their findings. I am right now (slowly) in the progress of writing a document, with demands to a solid, easy to understand build system, based on my experience from a system about 4-5 times bigger than AOO. Great! I look forward to it! Although I have *used* make systems a lot throughout my career, I've never ever constructed one, so much of this is a mystery to me. Me too and we can can benefit from something that we understand better and that is potentially not so generic but where makefiles are readable. +2 And, yes, I saw the gbuild branch was basically inactive and tried to tract down some info on that, but couldn't find much discussion about it. We do indeed need to devote discussion time to our build process after 4.0. I would hope we could at least make things simpler for folks wanting to partial builds of areas. In my world, we can make it VERY simple...but even though gbuild is pretty new, it uses the same philosofy as dmake, so it does not
Re: Make x Dmake x Build (Was: Re: [Error] Compile AOO on Debian amd64)
On 19.04.2013 07:56, Jürgen Schmidt wrote: On 4/19/13 12:33 AM, Kay Schenk wrote: On Thu, Apr 18, 2013 at 2:11 PM, janI j...@apache.org wrote: 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. When I last made a count for my ApacheCon talk we had 176 modules built with dmake and 18 built with gbuild. 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. I doubt that, too. I am also not sure if the right problems where addressed when gbuild was 'designed'. Two ways in which it failed completely are - build speed on Windows. gbuild was written on some *nix variant (probably Linux or Solaris) and optimized for that. Windows was not liked much by the gbuild developers, and that shows. - the gbuild system is probably harder to maintain than the dmake system. Maintainability is one of the key points in an open source project as large as ours. When only a select few can understand and maintain it, then that is not enough. I saw all this mixture too in my build experience, and well...couldn't figure out why. It seems historically dmake was used to speed things The dmake build system was 'invented' when computers where much slower than today, but the source code tree was not that much smaller. Global dependencies on file level could not have been reasonable modeled, just too much data. A solution for this are dependencies on module basis. This is what the first line in module/prj/build.lst provides. Full builds, even full builds of modules like sw took too much time to do on a regular basis. Therefore, when you changed a file in one directory, then you wanted to just compile this file or at most the whole directory and then build the affected libraries. All this is possible with the dmake system, which is basically directory based. Call build in module and it builds the whole module but got to directory in module and run dmake and it compiles just that directory. These dependencies of a module on its directories is described by the remaining lines in module/prj/build.lst. Computers are faster today, global dependencies have become a possible way to make the build process faster (ie compile less by only compiling files that depend on modified files) and more reliable (it is probably a missing inter-module dependency that sometimes breaks our build on the buildbot). That is what gbuild tries to do. But, if you know what you are doing and want to compile just a couple of files that you are interested in, then that is not possible anymore with gbuild. along, but, well...I'm not sure how/why it's being used now exactly. Actually the wiki/gbuild have a pretty good description. The people who started gbuild did a real good job of analyzing the dmake build and an even better job of documenting their findings. I am not so sure about that. One result of that analysis was that cmake would not be good tool to build AOO, with reasons that where challenged by one of cmakes developers (Bill Hoffman) but, as far as I know, never answered by the gbuild developers. To me, the analysis looked more like serving a predefined outcome. I am right now (slowly) in the progress of writing a document, with demands to a solid, easy to understand build system, based on my experience from a system about 4-5 times bigger than AOO. I am eagerly looking forward to reading what you are writing. I myself are working on a replacement for gbuild but that my turn out too experimental/radical for real world usage. But I am learning a lot about the inner workings of gbuild. Great! I look forward to it! Although I have *used* make systems a lot throughout my career, I've never ever constructed one, so much of this is a mystery to me. Me too and we can can benefit from something that we understand better and that is potentially not so generic but where makefiles are readable. And, yes, I saw the gbuild branch was basically inactive and tried to The gbuild branch is about
Re: Make x Dmake x Build (Was: Re: [Error] Compile AOO on Debian amd64)
On 19.04.2013 10:02, janI wrote: On 19 April 2013 07:56, Jürgen Schmidt jogischm...@gmail.com wrote: On 4/19/13 12:33 AM, Kay Schenk wrote: On Thu, Apr 18, 2013 at 2:11 PM, janI j...@apache.org wrote: On 18 April 2013 22:38, Kay Schenk kay.sch...@gmail.com wrote: On Thu, Apr 18, 2013 at 5:17 AM, janI j...@apache.org wrote: On 18 April 2013 14:08, Claudio Filho filh...@gmail.com wrote: Hi 2013/4/18 Oliver-Rainer Wittmann orwittm...@googlemail.com: 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
Re: Make x Dmake x Build (Was: Re: [Error] Compile AOO on Debian amd64)
On 19 April 2013 14:40, Andre Fischer awf@gmail.com wrote: On 19.04.2013 10:02, janI wrote: On 19 April 2013 07:56, Jürgen Schmidt jogischm...@gmail.com wrote: On 4/19/13 12:33 AM, Kay Schenk wrote: On Thu, Apr 18, 2013 at 2:11 PM, janI j...@apache.org wrote: On 18 April 2013 22:38, Kay Schenk kay.sch...@gmail.com wrote: On Thu, Apr 18, 2013 at 5:17 AM, janI j...@apache.org wrote: On 18 April 2013 14:08, Claudio Filho filh...@gmail.com wrote: Hi 2013/4/18 Oliver-Rainer Wittmann orwittm...@googlemail.com: 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. I am sure a single makefile would not really improve maintainability. But not going through 5 files, would speed up build time, so somewhere in between. Without going to much in detail, I see a big difference in how you specify the makefiles and what is actually running. In the project I worked with, we had configure, generate makefiles, I think aoo could benefit from that. 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
Re: [Error] Compile AOO on Debian amd64
Hi On 18.04.2013 00:28, Albino B Neto wrote: Hi I did it all again, look[1]. 1 - http://pastebin.com/mnB26Rk3 The information presented at the linked web resource does not show the error in module sw. But regarding the removed Slot FN_PROPERTY_WRAP_DLG perform a clean build of module sw: - cd sw - make clean - build Best regards, Oliver. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Error] Compile AOO on Debian amd64
On 17.04.2013 21:22, Albino B Neto wrote: 2013/4/17 Albino B Neto bino...@gmail.com: When you have fixed the errors in that module you can resume the build by running: build --all:sw When I running command buid --all:sw, look: == build -- version: 275224 Cannot determine source directory/repository for /home/albino/projetos/aoo/source/main at /home/albino/projetos/aoo/source/main/solenv/bin/build.pl line 1151 == You first have to change your directory to main/instsetoo_native before you build. Try this: cd /home/albino/projetos/aoo/source/main/instsetoo_native build --all:sw -Andre Albino - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Make x Dmake x Build (Was: Re: [Error] Compile AOO on Debian amd64)
Hi 2013/4/18 Oliver-Rainer Wittmann orwittm...@googlemail.com: 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. 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. In long term, we will migrate to Make or continue with this hibrid(?) model? Cheers, Claudio - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Make x Dmake x Build (Was: Re: [Error] Compile AOO on Debian amd64)
On 18 April 2013 14:08, Claudio Filho filh...@gmail.com wrote: Hi 2013/4/18 Oliver-Rainer Wittmann orwittm...@googlemail.com: 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). In long term, we will migrate to Make or continue with this hibrid(?) model? Yes, at the moment we have a branch called gbuild with very little activity. You can find a lot of description on wiki about gbuild. There are also ongoing work, to use standard make and a much simpler structure (no perl build), but this is not something you will see until after the 4.0 (and problaly 4.1) release. Once a complete is ready it will be published and hopefully discussed on this list. rgds jan I. Cheers, Claudio - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Error] Compile AOO on Debian amd64
2013/4/18 Albino B Neto bino...@gmail.com: And is running now the command build --all:sw, on directory main/instsetoo_native More error [1]. 1 - http://pastebin.com/HsCwnQRq I ran the command, but, still show error. Albino - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Error] Compile AOO on Debian amd64
On Apr 18, 2013, at 9:41 PM, Albino B Neto wrote: 2013/4/18 Pavel Janík pa...@janik.cz: Paste more so we see the actual error and not the message that there is an error in instsetoo_native ;-) Sorry :-P Look: http://pastebin.com/2NNAcKwt https://issues.apache.org/ooo/show_bug.cgi?id=121469 -- Pavel Janík - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Make x Dmake x Build (Was: Re: [Error] Compile AOO on Debian amd64)
On Thu, Apr 18, 2013 at 5:17 AM, janI j...@apache.org wrote: On 18 April 2013 14:08, Claudio Filho filh...@gmail.com wrote: Hi 2013/4/18 Oliver-Rainer Wittmann orwittm...@googlemail.com: 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 saw all this mixture too in my build experience, and well...couldn't figure out why. It seems historically dmake was used to speed things along, but, well...I'm not sure how/why it's being used now exactly. And, yes, I saw the gbuild branch was basically inactive and tried to tract down some info on that, but couldn't find much discussion about it. We do indeed need to devote discussion time to our build process after 4.0. I would hope we could at least make things simpler for folks wanting to partial builds of areas. In long term, we will migrate to Make or continue with this hibrid(?) model? Yes, at the moment we have a branch called gbuild with very little activity. You can find a lot of description on wiki about gbuild. There are also ongoing work, to use standard make and a much simpler structure (no perl build), but this is not something you will see until after the 4.0 (and problaly 4.1) release. Once a complete is ready it will be published and hopefully discussed on this list. rgds jan I. Cheers, Claudio - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- MzK There's no upside in screwing with things you can't explain. -- Captain Roy Montgomery, Castle
Re: Make x Dmake x Build (Was: Re: [Error] Compile AOO on Debian amd64)
On 18 April 2013 22:38, Kay Schenk kay.sch...@gmail.com wrote: On Thu, Apr 18, 2013 at 5:17 AM, janI j...@apache.org wrote: On 18 April 2013 14:08, Claudio Filho filh...@gmail.com wrote: Hi 2013/4/18 Oliver-Rainer Wittmann orwittm...@googlemail.com: 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 :-) 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. I saw all this mixture too in my build experience, and well...couldn't figure out why. It seems historically dmake was used to speed things along, but, well...I'm not sure how/why it's being used now exactly. Actually the wiki/gbuild have a pretty good description. The people who started gbuild did a real good job of analyzing the dmake build and an even better job of documenting their findings. I am right now (slowly) in the progress of writing a document, with demands to a solid, easy to understand build system, based on my experience from a system about 4-5 times bigger than AOO. And, yes, I saw the gbuild branch was basically inactive and tried to tract down some info on that, but couldn't find much discussion about it. We do indeed need to devote discussion time to our build process after 4.0. I would hope we could at least make things simpler for folks wanting to partial builds of areas. In my world, we can make it VERY simple...but even though gbuild is pretty new, it uses the same philosofy as dmake, so it does not really change things. I have a couple of ideas, admitted a bit radical, but they would allow us to use standard make. My intention is to take the discussion, when I have something to present, instead of starting the discussion with a piece of blank paper. Another thing we need to discuss is packaging, would it not be ideal if people could just make writer, when working on that. I would like to see a download page, where the user select which parts of AOO he/she wants to download. I hope you like to appetizer :-) rgds Jan I. In long term, we will migrate to Make or continue with this hibrid(?) model? Yes, at the moment we have a branch called gbuild with very little activity. You can find a lot of description on wiki about gbuild. There are also ongoing work, to use standard make and a much simpler structure (no perl build), but this is not something you will see until after the 4.0 (and problaly 4.1) release. Once a complete is ready it will be published and hopefully discussed on this list. rgds jan I. Cheers, Claudio - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- MzK There's no upside in screwing with things you can't explain. -- Captain Roy Montgomery, Castle
Re: Make x Dmake x Build (Was: Re: [Error] Compile AOO on Debian amd64)
On Thu, Apr 18, 2013 at 2:11 PM, janI j...@apache.org wrote: On 18 April 2013 22:38, Kay Schenk kay.sch...@gmail.com wrote: On Thu, Apr 18, 2013 at 5:17 AM, janI j...@apache.org wrote: On 18 April 2013 14:08, Claudio Filho filh...@gmail.com wrote: Hi 2013/4/18 Oliver-Rainer Wittmann orwittm...@googlemail.com: 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. I saw all this mixture too in my build experience, and well...couldn't figure out why. It seems historically dmake was used to speed things along, but, well...I'm not sure how/why it's being used now exactly. Actually the wiki/gbuild have a pretty good description. The people who started gbuild did a real good job of analyzing the dmake build and an even better job of documenting their findings. I am right now (slowly) in the progress of writing a document, with demands to a solid, easy to understand build system, based on my experience from a system about 4-5 times bigger than AOO. Great! I look forward to it! Although I have *used* make systems a lot throughout my career, I've never ever constructed one, so much of this is a mystery to me. And, yes, I saw the gbuild branch was basically inactive and tried to tract down some info on that, but couldn't find much discussion about it. We do indeed need to devote discussion time to our build process after 4.0. I would hope we could at least make things simpler for folks wanting to partial builds of areas. In my world, we can make it VERY simple...but even though gbuild is pretty new, it uses the same philosofy as dmake, so it does not really change things. I have a couple of ideas, admitted a bit radical, but they would allow us to use standard make. My intention is to take the discussion, when I have something to present, instead of starting the discussion with a piece of blank paper. Another thing we need to discuss is packaging, would it not be ideal if people could just make writer, when working on that. I would like to see a download page, where the user select which parts of AOO he/she wants to download. I hope you like to appetizer :-) So far, what you say makes very good sense to me. I'm happy you've started in this direction. rgds Jan I. In long term, we will migrate to Make or continue with this hibrid(?) model? Yes, at the moment we have a branch called gbuild with very little activity. You can find a lot of description on wiki about gbuild. There are also ongoing work, to use standard make and a much simpler structure (no perl build), but this is not something you will see until after the 4.0 (and problaly 4.1) release. Once a complete is ready it will be published and hopefully discussed on this list. rgds jan I. Cheers, Claudio - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- MzK There's no upside in screwing with things you can't explain. -- Captain Roy Montgomery, Castle -- MzK There's no upside in screwing with things you can't explain. -- Captain Roy
Re: Make x Dmake x Build (Was: Re: [Error] Compile AOO on Debian amd64)
On 4/19/13 12:33 AM, Kay Schenk wrote: On Thu, Apr 18, 2013 at 2:11 PM, janI j...@apache.org wrote: On 18 April 2013 22:38, Kay Schenk kay.sch...@gmail.com wrote: On Thu, Apr 18, 2013 at 5:17 AM, janI j...@apache.org wrote: On 18 April 2013 14:08, Claudio Filho filh...@gmail.com wrote: Hi 2013/4/18 Oliver-Rainer Wittmann orwittm...@googlemail.com: 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. I saw all this mixture too in my build experience, and well...couldn't figure out why. It seems historically dmake was used to speed things along, but, well...I'm not sure how/why it's being used now exactly. Actually the wiki/gbuild have a pretty good description. The people who started gbuild did a real good job of analyzing the dmake build and an even better job of documenting their findings. I am right now (slowly) in the progress of writing a document, with demands to a solid, easy to understand build system, based on my experience from a system about 4-5 times bigger than AOO. Great! I look forward to it! Although I have *used* make systems a lot throughout my career, I've never ever constructed one, so much of this is a mystery to me. Me too and we can can benefit from something that we understand better and that is potentially not so generic but where makefiles are readable. And, yes, I saw the gbuild branch was basically inactive and tried to tract down some info on that, but couldn't find much discussion about it. We do indeed need to devote discussion time to our build process after 4.0. I would hope we could at least make things simpler for folks wanting to partial builds of areas. In my world, we can make it VERY simple...but even though gbuild is pretty new, it uses the same philosofy as dmake, so it does not really change things. I have a couple of ideas, admitted a bit radical, but they would allow us to use standard make. My intention is to take the discussion, when I have something to present, instead of starting the discussion with a piece of blank paper. I am looking forward to hear, read or see more Another thing we need to discuss is packaging, would it not be ideal if people could just make writer, when working on that. I would like to see a download page, where the user select which parts of AOO he/she wants to download. I hope you like to appetizer :-) So far, what you say makes very good sense to me. I'm happy you've started in this direction. of course it make sense and is not really a new idea. But when you look closer you will see that the difference in the end is not really huge. But a simplified packaging process would be highly appreciated. I believe there is a lot of room for improvements, especially when we remove all the special cases that we no longer need. This would probably help us to provide a good working patch mechanism. The idea of dynamic packaging is an interesting one especially when I think about localized version. Most of the stuff is the same and
Re: [Error] Compile AOO on Debian amd64
On Apr 17, 2013, at 9:19 PM, Albino B Neto wrote: == ERROR: error 65280 occurred while making /home/albino/projetos/aoo/source/main/sw/prj When you have fixed the errors in that module you can resume the build by running: build --all:sw == I can't find solution. We can't help you, you have to show us the actual error. Show us cd sw build and copy the error... -- Pavel Janík - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Error] Compile AOO on Debian amd64
2013/4/17 Albino B Neto bino...@gmail.com: When you have fixed the errors in that module you can resume the build by running: build --all:sw When I running command buid --all:sw, look: == build -- version: 275224 Cannot determine source directory/repository for /home/albino/projetos/aoo/source/main at /home/albino/projetos/aoo/source/main/solenv/bin/build.pl line 1151 == Albino - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Error] Compile AOO on Debian amd64
2013/4/17 Pavel Janík pa...@janik.cz: cd sw build Look [1]. http://pastebin.com/EX8zuSb5 Albino - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Error] Compile AOO on Debian amd64
On Apr 17, 2013, at 9:26 PM, Albino B Neto wrote: 2013/4/17 Pavel Janík pa...@janik.cz: cd sw build Look [1]. /home/albino/projetos/aoo/source/main/solver/400/unxlngx6.pro/workdir/SdiTarget/sw/sdi/swslots.hxx:9874:5: error: 'FN_PROPERTY_WRAP_DLG' was not declared in this scope This is not your fault. Start again from scratch... It was deleted today. Start with the clean checkout and do clean build. -- Pavel Janík - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Error] Compile AOO on Debian amd64
Hi I did it all again, look[1]. 1 - http://pastebin.com/mnB26Rk3 Albino - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
