On 10/15/13 10:45 AM, janI wrote:
> On 15 October 2013 10:02, Andre Fischer <awf....@gmail.com> wrote:
> 
>> On 14.10.2013 23:40, janI wrote:
>>
>>> On 14 October 2013 23:34, Kay Schenk <kay.sch...@gmail.com> wrote:
>>>
>>>  On Mon, Oct 14, 2013 at 2:02 PM, janI <j...@apache.org> wrote:
>>>>
>>>>  On 14 October 2013 19:44, Kay Schenk <kay.sch...@gmail.com> wrote:
>>>>>
>>>>>  On Mon, Oct 14, 2013 at 12:38 AM, Andre Fischer <awf....@gmail.com>
>>>>>>
>>>>> wrote:
>>>>>
>>>>>> On 11.10.2013 18:10, janI wrote:
>>>>>>>
>>>>>>>  Hi.
>>>>>>>>
>>>>>>>> FYI: as I informed a while ago, I made a project proposal for OSU
>>>>>>>> capstone.
>>>>>>>>
>>>>>>>> The project has been selected, so we will have 4 students working
>>>>>>>>
>>>>>>> the
>>>>
>>>>> next
>>>>>>
>>>>>>> months to achieve the following:
>>>>>>>>
>>>>>>>>  That is great news.  Thank you for pushing this forward.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  http://eecs.oregonstate.edu/****capstone/viewproposal2013.php?**
>>>>>>>> **id=16<http://eecs.oregonstate.edu/**capstone/viewproposal2013.php?**id=16>
>>>>>>>>
>>>>>>> <
>>>>
>>>>> http://eecs.oregonstate.edu/**capstone/viewproposal2013.php?**id=16<http://eecs.oregonstate.edu/capstone/viewproposal2013.php?id=16>
>>>>>>>
>>>>>>
>>>>>>> extract from above:
>>>>>>>>
>>>>>>>> motivation:
>>>>>>>> "Apache OpenOffice is the biggest open source office package, with
>>>>>>>>
>>>>>>> 65
>>>>
>>>>> milllion downloads of our last version. A number of other open
>>>>>>>>
>>>>>>> source
>>>>
>>>>> packages are derived from OpenOffice, and incorporates patches and
>>>>>>>> enhancements from AOO.
>>>>>>>> The AOO source code is very big, 121 languages, 233 modules and 2933
>>>>>>>> makefiles (including sub-makefiles). As programming platform, we use
>>>>>>>>
>>>>>>> C++
>>>>>
>>>>>> (bulk part), Java, Python, Perl and some special libraries
>>>>>>>> The build system is old, a combination of perl and dmake, and has
>>>>>>>>
>>>>>>> grown
>>>>>
>>>>>> over the years into a non standard, hard to understand non
>>>>>>>>
>>>>>>> documented
>>>>
>>>>> system.
>>>>>>>> At the same time, we want to attract more developers, therefore we
>>>>>>>>
>>>>>>> want
>>>>>
>>>>>> to
>>>>>>
>>>>>>> make a new build system based on modern technology, which are easy
>>>>>>>>
>>>>>>> to
>>>>
>>>>> use
>>>>>>
>>>>>>> especially for windows developers."
>>>>>>>>
>>>>>>>> goal:
>>>>>>>> "The goal is to:
>>>>>>>> 1) make a build system suitable for use with microsoft visual studio
>>>>>>>> 2) make a build system suitable for use on linux (makefiles)
>>>>>>>> One of those systems should be the primary one and the other one
>>>>>>>>
>>>>>>> should
>>>>>
>>>>>> be
>>>>>>
>>>>>>> automatically generated.
>>>>>>>>
>>>>>>>>  I am not happy with that last sentence.   When there is one
>>>>>>> 'primary'
>>>>>>> flavor of the build system, then that tends to get much more
>>>>>>>
>>>>>> attention
>>>>
>>>>> than
>>>>>>
>>>>>>> the other flavors.  This happened with both build system that we
>>>>>>>
>>>>>> have.
>>>>
>>>>>   They heavily tend to the Unix side and are slow and hard to use on
>>>>>>>
>>>>>> Windows.
>>>>>>
>>>>>>> I think that we should treat our major platforms (Windows, Linux and
>>>>>>>
>>>>>> Mac)
>>>>>
>>>>>> equal.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> I plead absolute ignorance about Visual Studio 2008, but I thought it
>>>>>>
>>>>> could
>>>>>
>>>>>> use "makefile" specifications -- though maybe this is not
>>>>>>
>>>>> well-integrated
>>>>
>>>>> from what I've been reading.
>>>>>>
>>>>>>  Makefiles have been integrated since VC 6, but once you start using it
>>>>>
>>>> you
>>>>
>>>>> soon find the limits, it would never support a setup like ours.
>>>>>
>>>>>  OK...like I said, complete ignorance.  I have ONLY used *nix builds in
>>>> the
>>>> course of my life.
>>>>
>>>>  it maybe ignorance, I call it "interest", and to me all input are
>>> welcome !
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>  In my mind, it would be great to ditch build.pl if we could, and go
>>>>>>
>>>>> with a
>>>>>
>>>>>> straight makefile setup. We've already worked on this aspect.
>>>>>>
>>>>>>
>> I think build.pl is the smallest problem in our build problem.  As Jan
>> already said, it basically just calls dmake or GNU make for all projects
>> and in the right order.
>>
>>
>>  To ditch build.pl alone, is a very straight forward task, a real nice
>>>>>
>>>> task
>>>>
>>>>> for a new developer.
>>>>>
>>>>> Remember build only controls the <module>/prj directories and then call
>>>>> dmake to do the rest.
>>>>>
>>>>> Ditching build.pl (which I have done experimental for helpcontent2 and
>>>>> l10ntools) consist of:
>>>>> 1) take the first line of */prj/build.lst and use that to build a
>>>>>
>>>> Makefile
>>>>
>>>>> in with module dependencies.
>>>>> 2) for each module use the remaining lines in */prj/build.lst to build a
>>>>> <module>/Makefile that calls dmake for the existing makefiles
>>>>> 3) for each mdoule use */prj/deliver.lst to expand <module>/Makefile
>>>>>
>>>> with a
>>>>
>>>>> target and a set of copy instructions.
>>>>>
>>>>> It about a little workweek to edit and test the setup.
>>>>>
>>>>>
>> Some time ago I have written a Perl script that basically what Jan has
>> outlined.  It reads the build.lst files and creates one Makefile that calls
>> dmake and GNU make for the projects.
>> The only problem with this aproach, and the reason why I did not finalized
>> this experiment, is that build.pl has a lot of other features and options
>> besides the regular build.  Understanding these and replicating them is the
>> hard part.
>>
> 
> I would not mind having a copy of the script if possible ?
> 
> I think we need a big discussion to whether a new system should support all
> options and features of the existing systems.
> 
> As an example, we remove most (if not all) options in configure by having
> an option like "--generate_platform=xyz" where xyz is one of our supported
> release platforms. The --generate-platform would internally set the same
> options we use to generate the releases.
> 
> Going in such a direction will of course limit the build variations, but I
> am not sure if that is a bad thing ?

I don't know either but one goal should be to be able to build on a
modern unix system and build against the system libs. I believe this is
important to be included in Linux distros in the long term which I would
like to see ...

But having a cleanup configure and having such release or platform
switches to simplify things are potentially not a bad idea.


Juergen



Juergen



> 
> rgds
> jan I.
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Reply via email to