On 21 October 2013 15:52, Andre Fischer <awf....@gmail.com> wrote: > On 21.10.2013 12:35, janI wrote: > >> [...] >> >> I have the following plan: >> a) rename all Makefile to Makefile.gb, and correct prj/makefile.mk to the >> new name >> > > prj/makefile.mk usually only contains a simple forwarding. This would > mean that making a gbuild module would require two forwards, one from the > global Makefile to prj/makefile.mk and one from there to ./Makefile. > Maybe prj/makefile.mk could be removed and ./Makefile be called directly > from the global Makefile?
Would be a lot easier, I have looked at tweaking build.pl to accept make along with nmake, and then call make instead of dmake, but I have had a lot of success. Any help would be apriciated. > > > b) for each <module> add a new Makefile, that basically call the existing >> makefile.mk, as per your script (and build.lst) and update build.lst >> > > I would suggest to do this forwarding with a macro, so that when there are > any changes in the future, we only have to change the macro once instead of > every forwarding call. > A while back I modified the forwarding calls for gbuild modules (from prj/ > makefile.mk to ./Makefile) to include the debug flag. Would have been > easier when all had used the same macro. good idea. > > > c) add deliver.lst to Makefile and update build.lst >> > > Are deliver.lst and build.lst still used after this change? If not, can > you delete them? yes, I do that at a later step, when I am sure the new Makefile works. > > > >> once done, both build.pl and main/Makefile will work in the branch. >> >> d) have all of you test, and critic the idea. >> e) remove */prj and build.pl >> f) integrate in trunk. >> > > Sounds good to me, with or without changes according to my suggestions. > thx. rgds jan I. > > -Andre > > >> rgds >> jan I. >> >> >> >> >> -Andre >>> >>> >>> >>> hope you like it. >>>> rgds >>>> jan I. >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> While this is easy to do with eg Perl I am not sure how to handle >>>>>> >>>>>>> this >>>>>>> >>>>>>> with just a Makefile. The straightforward approach with handling >>>>>>>> <module>.done files does not work. And that is one of the reasons >>>>>>>> why >>>>>>>> >>>>>>>> I >>>>>>> >>>>>> don't think that (GNU) makefiles are a good solution for any problem. >>>>>> >>>>>>> Most >>>>>>>> of us are used to program object oriented/imperative. Makefiles >>>>>>>> >>>>>>>> require >>>>>>> >>>>>> a >>>>>> >>>>>>> declarative approach. Maybe the use of Perl is not such a bad idea. >>>>>>>> Maybe >>>>>>>> it would be better to reimplement build.pl with a lot fewer options >>>>>>>> >>>>>>>> and >>>>>>> >>>>>> with better readable code. >>>>>> >>>>>>> I agree that makefiles are nowhere near a good solution to many of >>>>>>>> >>>>>>>> these >>>>>>> >>>>>> problems, but its like windows, I dont like it, but everybody uses it. >>>>>> >>>>>>> We could easily write a new build.pl, that also took care of the >>>>>>> local >>>>>>> makefiles, but our build system would not be in the mainstream, and >>>>>>> e.g. >>>>>>> the distros would not like to integrate AOO. >>>>>>> >>>>>>> I have over the last years followed research in building systems, and >>>>>>> there >>>>>>> are (sadly enough) nobody that tries a real object oriented aproach. >>>>>>> >>>>>>> Also >>>>>> if you look at packages like visual studio, QT, eclipse they all use >>>>>> the >>>>>> >>>>>>> principle of makefiles with declarative approach. >>>>>>> >>>>>>> So my simple question is, do we want to approach the main road >>>>>>> >>>>>>> (makefiles >>>>>> for unix, visual studio for windows/mac) or do we want to have better >>>>>> but >>>>>> non standard system. >>>>>> >>>>>>> Good analysis. Maybe I should answer with Faust: "Zwei Seelen >>>>>>> wohnen, >>>>>>> >>>>>> ach! in meiner Brust" (two souls alas! are dwelling in my breast). >>>>>> The >>>>>> pragmatist says to use the make. It is good enough for others, it is >>>>>> >>>>>> good >>>>> >>>>> enough for use. >>>>>> On the other hand, when I start a new project I usually start with the >>>>>> question of what are the best tools for the problem at hand. And make >>>>>> >>>>>> does >>>>> >>>>> not seem to be the first or the best answer. Look at our dmake or >>>>>> gbuild >>>>>> system. Both don't use make in a standard way. gmake even defines its >>>>>> >>>>>> own >>>>> >>>>> language, object oriented and imperative, on top of the GNU make >>>>>> macros. >>>>>> That is, for me, an act of desperation. >>>>>> I have made experiments with an alternative approach, a domain >>>>>> specific >>>>>> language somewhat similar to Java. I personally like this approach >>>>>> >>>>>> because >>>>> >>>>> a) it uses the paradigm that I already use when writing C++ code. That >>>>>> means that I can apply my existing knowledge to the build process and >>>>>> >>>>>> that >>>>> >>>>> I don't have to remember all the tricks and pitfalls of makefiles. >>>>>> b) as expected it was much easier to handle file dependencies and >>>>>> >>>>>> parallel >>>>> >>>>> processing of build jobs in Java than adding object orientation and >>>>>> imperative control flow to makefiles. >>>>>> >>>>>> If I had the time and if I would be the one working on it then I would >>>>>> prefer an non-Makefile approach. But maybe I am just suffering too >>>>>> much >>>>>> from one of the 'three great virtues of a programmer': hubris. >>>>>> >>>>>> You are the one who leads the build project changes, so you have to >>>>>> >>>>>> decide >>>>> >>>>> which approach to use. I am not trying to make your life harder (than >>>>>> necessary), I am only trying to point out some of the pitfalls that I >>>>>> >>>>>> have >>>>> >>>>> encountered in the past. And to prevent you from removing features >>>>>> that >>>>>> >>>>>> I >>>>> >>>>> use :-) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> rgds >>>>>> >>>>>>> jan I. >>>>>>> >>>>>>> Ps. its always refreshing to discuss with you, you often have an >>>>>>> alternative approach, which is not just a dream but doable. >>>>>>> >>>>>>> Thanks. That makes two of us. >>>>>>> >>>>>> Have a nice weekend, >>>>>> Andre >>>>>> >>>>>> >>>>>> >>>>>> -Andre >>>>>> >>>>>>> --prepare >>>>>>>> >>>>>>>> Also one option that is important for our every day work. >>>>>>>>> Use >>>>>>>>> >>>>>>>>>> case: >>>>>>>>>> You make changes in <module> and are not sure if these changes are >>>>>>>>>> compatible/incompatible. To be on the safe side you discard the >>>>>>>>>> >>>>>>>>>> output >>>>>>>>> >>>>>>>> of >>>>>> >>>>>>> all depending modules. To save time you keep the output of all >>>>>>>>>> other >>>>>>>>>> modules. >>>>>>>>>> >>>>>>>>>> Often used together with '--from' like 'make --prepare >>>>>>>>>> --from >>>>>>>>>> svx' to >>>>>>>>>> prepare a build after making changes in svx. >>>>>>>>>> >>>>>>>>>> Documentation changed, funny thing is that svx does not clear >>>>>>>>>> correctly >>>>>>>>>> >>>>>>>>>> on >>>>>>>>>> >>>>>>>>> my ubuntu build. >>>>>>>>> >>>>>>>>> >>>>>>>>> --since <module> >>>>>>>>> >>>>>>>>> A variant of '--from'. The only difference is that >>>>>>>>> <module> >>>>>>>>> >>>>>>>>>> itself >>>>>>>>>> is >>>>>>>>>> not built. >>>>>>>>>> >>>>>>>>>> If your proposed approach is similar to what my script >>>>>>>>>> produces >>>>>>>>>> then >>>>>>>>>> it >>>>>>>>>> is not too difficult to support --from/--since. I made some >>>>>>>>>> experiments >>>>>>>>>> in >>>>>>>>>> this direction but was to lazy to finish them. >>>>>>>>>> >>>>>>>>>> My approach is very similar, but I failed to see how --since >>>>>>>>>> is >>>>>>>>>> >>>>>>>>>> supported. >>>>>>>>>> >>>>>>>>> And question is if its real important. >>>>>>>>> >>>>>>>>> >>>>>>>>> --job >>>>>>>>> >>>>>>>>> --pre_job >>>>>>>>> >>>>>>>>>> --post_job >>>>>>>>>> These are sometimes handy to run a non-standard command for >>>>>>>>>> all >>>>>>>>>> modules. >>>>>>>>>> >>>>>>>>>> I have added them, they are by the way a good example why we >>>>>>>>>> need a >>>>>>>>>> >>>>>>>>>> discussion I have never used them. >>>>>>>>>> >>>>>>>>> However maybe the real discussion is "do we want to replace build >>>>>>>>> and >>>>>>>>> have >>>>>>>>> a main/Makefile instead?" >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> - I have not used the rest of the unsupported options and would >>>>>>>>> not >>>>>>>>> miss >>>>>>>>> >>>>>>>>> them. Others may have other sets of options that are important >>>>>>>>> to >>>>>>>>> >>>>>>>>>> them. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Some general remarks: >>>>>>>>>> >>>>>>>>>> - Why keep one makefile per module? Why not put all the >>>>>>>>>> inter-module >>>>>>>>>> dependencies into one file (like my script does)? >>>>>>>>>> >>>>>>>>>> Ups, I did not explain that correctly, I propose 1 Makefile >>>>>>>>>> >>>>>>>>>> "main/Makefile" >>>>>>>>>> >>>>>>>>> with all inter-module and 1 Makefile "<module>/Makefile" that today >>>>>>>>> >>>>>>>>> just >>>>>>>> >>>>>>> will call the old makefiles as described in prj/build.lst >>>>>> >>>>>>> - Why not use the oportunity to move (a part of) the build >>>>>>>>> environment >>>>>>>>> out >>>>>>>>> >>>>>>>>> of the way to, say, build/ ? >>>>>>>>> >>>>>>>>> You have guessed my next step. >>>>>>>>>> >>>>>>>>>> - How are dependencies between modules handled (just the >>>>>>>>>> manual >>>>>>>>>> >>>>>>>>> dependencies from prj/build.lst or also the file dependencies >>>>>>>>> >>>>>>>>>> introduced >>>>>>>>>> by >>>>>>>>>> gmake). >>>>>>>>>> >>>>>>>>>> See doc. on --from. Its done with <module>.done files >>>>>>>>>> >>>>>>>>>> - How is the output of the individual calls to dmake or GNU >>>>>>>>>> make >>>>>>>>>> >>>>>>>>> handled/made accessible. Ie. if there is a build error, how can >>>>>>>>> I >>>>>>>>> look >>>>>>>>> >>>>>>>> up >>>>>> >>>>>>> the corresponding build output? >>>>>>>>>> >>>>>>>>>> see doc. script make_log >>>>>>>>>> >>>>>>>>>> - Are the gmake makefiles included (run in the same process) >>>>>>>>>> or >>>>>>>>>> >>>>>>>>> is >>>>>>>>> >>>>>>>>> GNU >>>>>>>> >>>>>>> make started for them it its own process? >>>>>> >>>>>>> For a start they would be called (own process), but its something >>>>>>>>>> where >>>>>>>>>> >>>>>>>>>> I >>>>>>>>>> >>>>>>>>> have no strong opinions. >>>>>>>>> >>>>>>>>> Please (just to be sure), this proposal has nothing to do with the >>>>>>>>> students >>>>>>>>> work, its simply because I saw a positive discussion on removing >>>>>>>>> build.pl >>>>>>>>> , >>>>>>>>> and spent a couple of hours looking at it. If there is a preference >>>>>>>>> >>>>>>>>> not >>>>>>>> >>>>>>> to >>>>>> >>>>>>> remove build.pl I will simply forget it. >>>>>>>>> >>>>>>>>> rgds >>>>>>>>> jan I. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Andre >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It has been roughly tested it, thanks to a clever utility from >>>>>>>>>> >>>>>>>>>> andre. >>>>>>>>> >>>>>>>> As discussed build.pl contains a lot of options, which need to be >>>>>> >>>>>>> considered in a makefile. >>>>>>>>>>> >>>>>>>>>>> My suggestion is on >>>>>>>>>>> http://wiki.openoffice.org/**********wiki/Build_System_** >>>>>>>>>>> Analysis:****<http://wiki.openoffice.org/********wiki/Build_System_Analysis:****> >>>>>>>>>>> <http://wiki.**openoffice.org/******wiki/** >>>>>>>>>>> Build_System_Analysis:**<http://wiki.openoffice.org/******wiki/Build_System_Analysis:**> >>>>>>>>>>> > >>>>>>>>>>> < >>>>>>>>>>> >>>>>>>>>>> http://wiki.openoffice.org/********wiki/Build_System_Analysis:* >>>>>>>>>> ***<http://wiki.openoffice.org/******wiki/Build_System_Analysis:**> >>>>>>>>>> <http://wiki.openoffice.org/******wiki/Build_System_**Analysis:**<http://wiki.openoffice.org/****wiki/Build_System_Analysis:**> >>>>>>>>>> > >>>>>>>>>> >>>>>>>>> **> >>>>> >>>>> **<http://wiki.openoffice.org/********wiki/Build_System_**** >>>>>> Analysis:**<http://wiki.openoffice.org/******wiki/Build_System_**Analysis:**> >>>>>> <http://wiki.**openoffice.org/****wiki/Build_**System_Analysis:**<http://wiki.openoffice.org/****wiki/Build_System_Analysis:**> >>>>>> > >>>>>> >>>>>> < >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://wiki.openoffice.org/******wiki/Build_System_Analysis:**<http://wiki.openoffice.org/****wiki/Build_System_Analysis:**> >>>>>>>>>> **<http://wiki.openoffice.org/****wiki/Build_System_Analysis:**<http://wiki.openoffice.org/**wiki/Build_System_Analysis:**> >>>>>>>>>> > >>>>>>>>>> >>>>>>>>> build.pl_versus_makefile<http:********//wiki.openoffice.org/**** >>>>>> wiki/**** <http://wiki.openoffice.org/**wiki/****><http://wiki.** >>>>>> openoffice.org/wiki/**** <http://wiki.openoffice.org/wiki/****>> >>>>>> >>>>>>> < >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://wiki.openoffice.org/****wiki/**<http://wiki.openoffice.org/**wiki/**> >>>>>>>>>> <http://wiki.**openoffice.org/wiki/**<http://wiki.openoffice.org/wiki/**> >>>>>>>>>> > >>>>>>>>>> >>>>>>>>> Build_System_Analysis:build.********pl_versus_makefile<http://**** >>>>>> >>>>>>> wiki.openoffice.org/wiki/******Build_System_Analysis:build.**<http://wiki.openoffice.org/wiki/****Build_System_Analysis:build.**> >>>>>>>>>>> **<http://wiki.openoffice.org/**wiki/**Build_System_Analysis:** >>>>>>>>>>> build.**<http://wiki.openoffice.org/wiki/**Build_System_Analysis:build.**> >>>>>>>>>>> > >>>>>>>>>>> pl_versus_makefile< >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://wiki.openoffice.org/****wiki/Build_System_Analysis:**<http://wiki.openoffice.org/**wiki/Build_System_Analysis:**> >>>>>>>>>> >>>>>>>>> build.pl_versus_makefile<http:**//wiki.openoffice.org/wiki/** >>>>> Build_System_Analysis:build.**pl_versus_makefile<http://wiki.openoffice.org/wiki/Build_System_Analysis:build.pl_versus_makefile> >>>>> > >>>>> >>>>> Please feel free to edit/comment on the page. I have reduced to >>>>>> >>>>>>> options >>>>>>>>>>> a >>>>>>>>>>> lot, and some of them might be in use. >>>>>>>>>>> >>>>>>>>>>> thanks in advance for your comments. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ------------------------------** >>>>>>>>>>> ********----------------------**--* >>>>>>>>>>> *--** >>>>>>>>>>> --** >>>>>>>>>>> >>>>>>>>>>> --**--------- >>>>>>>>>>> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.********a** >>>>>>>>>> pache.org< >>>>>>>>>> http://apache.org**> >>>>>>>>>> <dev-unsubscribe@**openoffice.******apache.org< >>>>>>>>>> >>>>>>>>>> http://openoffice.apache.org> >>>>>>>>> >>>>>>>> <dev-unsubscribe@**openoffice.****apache.org<http://** >>>>>> openoffice.apache.org <http://openoffice.apache.org>> >>>>>> >>>>>> < >>>>>>>>>> >>>>>>>>>> dev-unsubscribe@openoffice.**a**pache.org <http://apache.org>< >>>>>>>>> dev-unsubscribe@**openoffice.apache.org<dev-unsubscr...@openoffice.apache.org> >>>>>>>>> > >>>>>>>>> >>>>>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>>>>> >>>>>>> >>>>>>>>>> >>>>>>>>>> ------------------------------********------------------------ >>>>>>>>>> **--** >>>>>>>>>> --** >>>>>>>>>> >>>>>>>>>> --**--------- >>>>>>>>> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.******a** >>>>>>>> pache.org< >>>>>>>> >>>>>>>> http://apache.org> >>>>>>> >>>>>> <dev-unsubscribe@**openoffice.****apache.org<http://** >>>>>> openoffice.apache.org <http://openoffice.apache.org>> >>>>>> >>>>>> < >>>>>>>> >>>>>>>> dev-unsubscribe@openoffice.**a**pache.org <http://apache.org>< >>>>>>> dev-unsubscribe@**openoffice.apache.org<dev-unsubscr...@openoffice.apache.org> >>>>>>> > >>>>>>> >>>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>>>>> >>>>>>> >>>>>>>> >>>>>>>> ------------------------------******--------------------------** >>>>>>>> --** >>>>>>>> >>>>>>> --**--------- >>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.****a**pache.org< >>>>>> http://apache.org**> >>>>>> < >>>>>> >>>>>> dev-unsubscribe@openoffice.**a**pache.org <http://apache.org>< >>>>> dev-unsubscribe@**openoffice.apache.org<dev-unsubscr...@openoffice.apache.org> >>>>> > >>>>> >>>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>> >>>>> ------------------------------****----------------------------**--** >>>>> ------------------------------****------- >>>>> >>>>> MzK >>>>> >>>>> "Truth is stranger than fiction, but it is because Fiction is obliged >>>>> to stick to possibilities. Truth isn't." >>>>> -- "Following the Equator", Mark Twain >>>>> >>>>> >>>>> ------------------------------****----------------------------** >>> --**--------- >>> To unsubscribe, e-mail: >>> dev-unsubscribe@openoffice.**a**pache.org<http://apache.org> >>> <dev-unsubscribe@**openoffice.apache.org<dev-unsubscr...@openoffice.apache.org> >>> > >>> >>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>> >>> >>> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@openoffice.**apache.org<dev-unsubscr...@openoffice.apache.org> > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
