Re: apache open office 4.1.7

2019-10-30 Thread Pedro Lino 
Ciao Paolo

Assuming you want the Italian version, you can download it directly from Apache
http://archive.apache.org/dist/openoffice/4.1.7/binaries/it/Apache_OpenOffice_4.1.7_Win_x86_install_it.exe

http://archive.apache.org/dist/openoffice/4.1.7/binaries/it/
Hope this helps,
Pedro

> On October 30, 2019 at 10:37 AM paolo gosetti < paolo.gose...@gmail.com 
> mailto:paolo.gose...@gmail.com > wrote:
> 
> 
> Perchè non riesco a scaricare la nuova versione del vs programma 4.1.7?
> Ogni volta che ci provo mi si apre una finestra con la dicitura Oh no!
> Impossibile
> caricare alcuni stili. Prova a ricaricare questa pagina o contatta
> l'assistenza < https://sourceforge.net/support> .
> 
> sistema operativo WINDOWS 10 HOME.
> IN ATTESA DI UNA VS CORTESE RISPOSTA PORGO DISTINTI SALUTI
> Paolo Gosetti
>

Re: apache open office 4.1.7

2019-10-30 Thread Marcus 

Am 30.10.19 um 11:37 schrieb paolo gosetti:

Perchè non riesco a scaricare la nuova versione del vs programma 4.1.7?
Ogni volta che ci provo mi si apre una finestra con la dicitura Oh no!
Impossibile
caricare alcuni stili. Prova a ricaricare questa pagina o contatta
l'assistenza  .

sistema operativo WINDOWS 10 HOME.
IN ATTESA DI UNA VS CORTESE RISPOSTA PORGO DISTINTI SALUTI


English translation via Google:

Why can't I download the new version of the 4.1.7 program?
Every time I try, a window opens with the word Oh no! Some styles cannot 
be loaded. Try reloading this page or contact support.


WINDOWS 10 HOME operating system.
WAITING FOR A CORTESE VS REPLY PORTO DISTINTI SALUTI



First please note that this is an internationl mailing list. Therefore 
please write in English language, so that everyone has a chance to give 
an answer. Otherwise we are not able to provide any help.


Back to your problem:

I've downloaded a second ago and haven't seen a problem. So, in general 
it's working.


When you have problems with specific mirror servers then just change 
them. On the SourceForge webpage there is a grey "Problems Downloading?" 
button. Just click on it and choose a different mirror from the popup 
dialog.


HTH

Marcus


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

Re: [DISCUSSION] Build environment future

2019-10-30 Thread Marcus 

Am 30.10.19 um 08:06 schrieb Patricia Shanahan:
As a user of the build system, I think we have too many build 
strategies, and should not add another one unless it is absolutely 
essential to do so. Of course I would prefer an IDE, but another round 
of build system changes is far too high a price to pay.


Given that most is on gmake, I would much prefer to stick with gmake.

If we keep changing our collective mind about the build system we will 
never have a consistent system, but will always have some modules on 
each of several systems.


strong +1

Otherwise the probability and risk is high that someone start with 
another build system and does not bring it to the end. Then we have just 
another partly working one - and the complexity is reaching new heights 
that nobody wants.


Marcus




On 10/29/2019 10:25 PM, Peter Kovacs wrote:

Hello Damjan and all


I would like to re-discuss our current plan. Hoping to gain a common 
view.


Current state is mostly we use gmake, there are still some difficult to
migrate dmake projects. And we use Ant for java.

The plan is not to stop at the dmake -> gmake conversion but to move on
to scons, removing as much dependencies as we can. Right?

I would like to set the target to build everything to Ant, removing as
much dependencies we can.


My arguments are mostly that Ant is supported by most when not all IDEs
and I would really like to have an IDE as working environment, and my
hope is that it is easier maybe to integrate an Ant build environment
then a scons or gmake environment.

  I think this would give us a better base then the plan above. So what
was the arguments against Ant again?



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

Re: New computer

2019-10-30 Thread Kay Schenk 


On 10/30/19 11:01 AM, Damjan Jovanovic wrote:

On Wed, Oct 30, 2019 at 6:16 PM Patricia Shanahan  wrote:


On 10/30/2019 8:13 AM, Damjan Jovanovic wrote:

What do you already know? SVN?

RCS, SCCS, and SVN.


I personally did:
git clone https://gitbox.apache.org/repos/asf/openoffice.git
(ie. not GitHub)
which I think used my Apache credentials. If you prefer to clone from
GitHub, and want to link your Apache and GitHub credentials, you can
apparently do it on:
https://gitbox.apache.org/

Any guidance on how to decide which I am likely to prefer?



It doesn't really matter which you start with, because they're each other's
mirrors, and in Git you can always change your local repository's "remote".
For example if you cloned GitHub, and want to switch to GitBox, you don't
need to clone the GitBox link, you can simply do:
git remote set-url origin https://gitbox.apache.org/repos/asf/openoffice.git

With GitHub, you can accept GitHub pull requests from other contributors,
even in your web browser, so it might be a better choice in that regard. I
can't say I personally approve of the GitHub lock-in for that feature
though.



As for how you use Git, if you are interested, I can give you some links,
and my own "Git for SVN users" crash course.

Links would be useful. For me when learning programming languages, "for
dummies" courses work better than conversion courses. The "for dummies"
type of course helps me get into the right mindset for the language. I
don't know whether SVN to Git will be different.



Ok sure:

Graph theory explanations of how branches and Git operations work:
https://eagain.net/articles/git-for-computer-scientists/

The free online book, "Pro Git":
https://git-scm.com/book/en/v2

A detailed guide to various Git options, written for the Wine project but
generally useful:
https://wiki.winehq.org/Git_Wine_Tutorial

I'll try sum it up for you. For SVN users, Git's terminology is straight
from hell. "svn checkout X" checks out a working copy from repository X,
but "git checkout X" switches the current branch to X (among other things).
Git's equivalent is "git clone" (except that the entire repository with
full history and all branches is cloned, not just a working copy.) An SVN
revision is a commit in Git.

Everything you commit is only committed locally, and can be undone. You
have to "git push" to send your commits upstream.

The main branch of a project is usually called "master", but in AOO ours is
called "trunk" since we imported from SVN. The branch you are on at the
moment is given by "git branch", which lists all the local branches and
stars the current one. "git status" also shows your current branch and
files changed.

Remote branches can be shown with "git remote show origin". If you "git
checkout" with their name, eg. "git checkout AOO418", it will make a local
branch by that name and switch to it. You can also make a local branch
remote (somehow).

You make new local branches with "git branch ", eg. "git branch
temp". (It's instantaneous: it doesn't have to copy history or anything
like that). You can "git checkout temp" to switch to it, "git branch -D
temp" to delete it. A "detached head" is when you "git checkout" something
that's not a branch (as you can "git checkout" any commit or tag, not just
a branch). If you are just looking around, that's not a problem, but if you
"git commit" on a detached head, that commit isn't referenced from
anywhere, and if you checkout anything else, you will lose that work. If
you don't want to lose it, you can "git branch myWork" to attach a branch
to that new commit, so you can get back to it later (with "git checkout
myWork").

There are 2 important ways of working with branches, merging and rebasing.
Both are only local, until you "git push". Merging in Git is similar to
merging in SVN, changes in one branch get merged into another, but rebasing
is amazing. With rebasing you can rearrange commits and branches to your
liking, split commits, merge commits, reorder commits, delete commits,
change commit messages, reposition an old branch so it starts at a newer
commit (and deal with outdated code locally in that branch before merging
or pushing it), etc. "git rebase -i HEAD~3" opens a text editor with the
last 3 commits, one per line, describing changes you can make by placing a
keyword at the beginning of its line. If you commit by mistake, do that and
you can drop the bad commit. Of course with great power comes great
responsibility, and rebasing should only really be done locally before you
push, as rebasing commits that were already pushed can mess up other
people's changes to them.

When changes are made upstream by other contributors, you can "git pull"
them, but I prefer the more incremental "git fetch" which fetches changes
without merging them, and then a rebase of my work to come after the latest
changes - that way I know those changes still apply, even if I don't push
them yet. ("git pull" does a "git fetch" and then a merge, not a

apache open office 4.1.7

2019-10-30 Thread paolo gosetti 
Perchè non riesco a scaricare la nuova versione del vs programma 4.1.7?
Ogni volta che ci provo mi si apre una finestra con la dicitura Oh no!
Impossibile
caricare alcuni stili. Prova a ricaricare questa pagina o contatta
l'assistenza  .

sistema operativo WINDOWS 10 HOME.
IN ATTESA DI UNA VS CORTESE RISPOSTA PORGO DISTINTI SALUTI
Paolo Gosetti

Re: New computer

2019-10-30 Thread Patricia Shanahan 

Thanks for the write up and links.

On 10/30/2019 11:01 AM, Damjan Jovanovic wrote:

On Wed, Oct 30, 2019 at 6:16 PM Patricia Shanahan  wrote:


On 10/30/2019 8:13 AM, Damjan Jovanovic wrote:

What do you already know? SVN?


RCS, SCCS, and SVN.



I personally did:
git clone https://gitbox.apache.org/repos/asf/openoffice.git
(ie. not GitHub)
which I think used my Apache credentials. If you prefer to clone from
GitHub, and want to link your Apache and GitHub credentials, you can
apparently do it on:
https://gitbox.apache.org/


Any guidance on how to decide which I am likely to prefer?



It doesn't really matter which you start with, because they're each other's
mirrors, and in Git you can always change your local repository's "remote".
For example if you cloned GitHub, and want to switch to GitBox, you don't
need to clone the GitBox link, you can simply do:
git remote set-url origin https://gitbox.apache.org/repos/asf/openoffice.git

With GitHub, you can accept GitHub pull requests from other contributors,
even in your web browser, so it might be a better choice in that regard. I
can't say I personally approve of the GitHub lock-in for that feature
though.


I definitely want to avoid GitHub lock-in. I've seen too many services 
change their terms to be comfortable depending too much on one.







As for how you use Git, if you are interested, I can give you some links,
and my own "Git for SVN users" crash course.


Links would be useful. For me when learning programming languages, "for
dummies" courses work better than conversion courses. The "for dummies"
type of course helps me get into the right mindset for the language. I
don't know whether SVN to Git will be different.



Ok sure:

Graph theory explanations of how branches and Git operations work:
https://eagain.net/articles/git-for-computer-scientists/


This looks like the best starting point for me. I am very comfortable 
with basic graph theory, including DAGs.




The free online book, "Pro Git":
https://git-scm.com/book/en/v2

A detailed guide to various Git options, written for the Wine project but
generally useful:
https://wiki.winehq.org/Git_Wine_Tutorial



I'll try sum it up for you. For SVN users, Git's terminology is straight
from hell. "svn checkout X" checks out a working copy from repository X,
but "git checkout X" switches the current branch to X (among other things).
Git's equivalent is "git clone" (except that the entire repository with
full history and all branches is cloned, not just a working copy.) An SVN
revision is a commit in Git.


So I should really forget SVN, go back to basics, and learn Git on its 
own terms from scratch.


I'll read the rest of this after the graph theory web site.



Everything you commit is only committed locally, and can be undone. You
have to "git push" to send your commits upstream.

The main branch of a project is usually called "master", but in AOO ours is
called "trunk" since we imported from SVN. The branch you are on at the
moment is given by "git branch", which lists all the local branches and
stars the current one. "git status" also shows your current branch and
files changed.

Remote branches can be shown with "git remote show origin". If you "git
checkout" with their name, eg. "git checkout AOO418", it will make a local
branch by that name and switch to it. You can also make a local branch
remote (somehow).

You make new local branches with "git branch ", eg. "git branch
temp". (It's instantaneous: it doesn't have to copy history or anything
like that). You can "git checkout temp" to switch to it, "git branch -D
temp" to delete it. A "detached head" is when you "git checkout" something
that's not a branch (as you can "git checkout" any commit or tag, not just
a branch). If you are just looking around, that's not a problem, but if you
"git commit" on a detached head, that commit isn't referenced from
anywhere, and if you checkout anything else, you will lose that work. If
you don't want to lose it, you can "git branch myWork" to attach a branch
to that new commit, so you can get back to it later (with "git checkout
myWork").

There are 2 important ways of working with branches, merging and rebasing.
Both are only local, until you "git push". Merging in Git is similar to
merging in SVN, changes in one branch get merged into another, but rebasing
is amazing. With rebasing you can rearrange commits and branches to your
liking, split commits, merge commits, reorder commits, delete commits,
change commit messages, reposition an old branch so it starts at a newer
commit (and deal with outdated code locally in that branch before merging
or pushing it), etc. "git rebase -i HEAD~3" opens a text editor with the
last 3 commits, one per line, describing changes you can make by placing a
keyword at the beginning of its line. If you commit by mistake, do that and
you can drop the bad commit. Of course with great power comes great
responsibility, and rebasing should only really be done locally

Re: New computer

2019-10-30 Thread Damjan Jovanovic 
On Wed, Oct 30, 2019 at 6:16 PM Patricia Shanahan  wrote:

> On 10/30/2019 8:13 AM, Damjan Jovanovic wrote:
> > What do you already know? SVN?
>
> RCS, SCCS, and SVN.
>
> >
> > I personally did:
> > git clone https://gitbox.apache.org/repos/asf/openoffice.git
> > (ie. not GitHub)
> > which I think used my Apache credentials. If you prefer to clone from
> > GitHub, and want to link your Apache and GitHub credentials, you can
> > apparently do it on:
> > https://gitbox.apache.org/
>
> Any guidance on how to decide which I am likely to prefer?
>
>
It doesn't really matter which you start with, because they're each other's
mirrors, and in Git you can always change your local repository's "remote".
For example if you cloned GitHub, and want to switch to GitBox, you don't
need to clone the GitBox link, you can simply do:
git remote set-url origin https://gitbox.apache.org/repos/asf/openoffice.git

With GitHub, you can accept GitHub pull requests from other contributors,
even in your web browser, so it might be a better choice in that regard. I
can't say I personally approve of the GitHub lock-in for that feature
though.


> >
> > As for how you use Git, if you are interested, I can give you some links,
> > and my own "Git for SVN users" crash course.
>
> Links would be useful. For me when learning programming languages, "for
> dummies" courses work better than conversion courses. The "for dummies"
> type of course helps me get into the right mindset for the language. I
> don't know whether SVN to Git will be different.
>
>
Ok sure:

Graph theory explanations of how branches and Git operations work:
https://eagain.net/articles/git-for-computer-scientists/

The free online book, "Pro Git":
https://git-scm.com/book/en/v2

A detailed guide to various Git options, written for the Wine project but
generally useful:
https://wiki.winehq.org/Git_Wine_Tutorial

I'll try sum it up for you. For SVN users, Git's terminology is straight
from hell. "svn checkout X" checks out a working copy from repository X,
but "git checkout X" switches the current branch to X (among other things).
Git's equivalent is "git clone" (except that the entire repository with
full history and all branches is cloned, not just a working copy.) An SVN
revision is a commit in Git.

Everything you commit is only committed locally, and can be undone. You
have to "git push" to send your commits upstream.

The main branch of a project is usually called "master", but in AOO ours is
called "trunk" since we imported from SVN. The branch you are on at the
moment is given by "git branch", which lists all the local branches and
stars the current one. "git status" also shows your current branch and
files changed.

Remote branches can be shown with "git remote show origin". If you "git
checkout" with their name, eg. "git checkout AOO418", it will make a local
branch by that name and switch to it. You can also make a local branch
remote (somehow).

You make new local branches with "git branch ", eg. "git branch
temp". (It's instantaneous: it doesn't have to copy history or anything
like that). You can "git checkout temp" to switch to it, "git branch -D
temp" to delete it. A "detached head" is when you "git checkout" something
that's not a branch (as you can "git checkout" any commit or tag, not just
a branch). If you are just looking around, that's not a problem, but if you
"git commit" on a detached head, that commit isn't referenced from
anywhere, and if you checkout anything else, you will lose that work. If
you don't want to lose it, you can "git branch myWork" to attach a branch
to that new commit, so you can get back to it later (with "git checkout
myWork").

There are 2 important ways of working with branches, merging and rebasing.
Both are only local, until you "git push". Merging in Git is similar to
merging in SVN, changes in one branch get merged into another, but rebasing
is amazing. With rebasing you can rearrange commits and branches to your
liking, split commits, merge commits, reorder commits, delete commits,
change commit messages, reposition an old branch so it starts at a newer
commit (and deal with outdated code locally in that branch before merging
or pushing it), etc. "git rebase -i HEAD~3" opens a text editor with the
last 3 commits, one per line, describing changes you can make by placing a
keyword at the beginning of its line. If you commit by mistake, do that and
you can drop the bad commit. Of course with great power comes great
responsibility, and rebasing should only really be done locally before you
push, as rebasing commits that were already pushed can mess up other
people's changes to them.

When changes are made upstream by other contributors, you can "git pull"
them, but I prefer the more incremental "git fetch" which fetches changes
without merging them, and then a rebase of my work to come after the latest
changes - that way I know those changes still apply, even if I don't push
them yet. ("git pull" does a "git fetch" and then

Re: New computer

2019-10-30 Thread Patricia Shanahan 

On 10/30/2019 8:13 AM, Damjan Jovanovic wrote:

What do you already know? SVN?


RCS, SCCS, and SVN.



I personally did:
git clone https://gitbox.apache.org/repos/asf/openoffice.git
(ie. not GitHub)
which I think used my Apache credentials. If you prefer to clone from
GitHub, and want to link your Apache and GitHub credentials, you can
apparently do it on:
https://gitbox.apache.org/


Any guidance on how to decide which I am likely to prefer?



As for how you use Git, if you are interested, I can give you some links,
and my own "Git for SVN users" crash course.


Links would be useful. For me when learning programming languages, "for 
dummies" courses work better than conversion courses. The "for dummies" 
type of course helps me get into the right mindset for the language. I 
don't know whether SVN to Git will be different.





On Wed, Oct 30, 2019 at 2:00 PM Patricia Shanahan  wrote:


I detangled the cables the hard way - shut everything down, unplugged,
detangled, and put it back together with only the cables that are
currently being used.

Now I do need some advice. What is the best starting point for learning
Git-for-AOO? I do have a GitHub account, with my personal e-mail address
not my apache.org address.

On 10/28/2019 11:33 AM, Patricia Shanahan wrote:

Thanks, but what I need is a magic wand of cable untangling I don't
suppose you have one handy.

In installing my new computer I found that the cables connecting various
computers, displays, router, and printer are a mess.

On 10/28/2019 9:51 AM, Matthias Seidel wrote:

Hi Patricia,

How are things going?
If you are in need of something just let me know...

Regards,

 Matthias

Am 26.10.19 um 06:24 schrieb Patricia Shanahan:

Any opinions on which I should do?


On 10/25/2019 1:27 PM, Matthias Seidel wrote:

Hi Patricia,

If you want to build 4.1.x have a look at:
https://home.apache.org/~mseidel/AOO-builds/AOO-418-Test/ReadMe.txt

For 4.2.x (and trunk) see:
https://home.apache.org/~mseidel/AOO-builds/AOO-420-Test/ReadMe.txt

This is how I do my test builds.

Regards,

  Matthias

Am 24.10.19 um 22:09 schrieb Patricia Shanahan:

Are the Windows 10 instructions up-to-date?

I have just got a shiny new Windows 10 Pro computer, and am planning

a

clean start on AOO building. It will take a day or so for me to
install and set up basic stuff, and then I'll need to install

whatever

I need for AOO building.

-
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








--
This email has been checked for viruses by AVG.
https://www.avg.com


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






--
This email has been checked for viruses by AVG.
https://www.avg.com


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

Re: New computer

2019-10-30 Thread Damjan Jovanovic 
What do you already know? SVN?

I personally did:
git clone https://gitbox.apache.org/repos/asf/openoffice.git
(ie. not GitHub)
which I think used my Apache credentials. If you prefer to clone from
GitHub, and want to link your Apache and GitHub credentials, you can
apparently do it on:
https://gitbox.apache.org/

As for how you use Git, if you are interested, I can give you some links,
and my own "Git for SVN users" crash course.


On Wed, Oct 30, 2019 at 2:00 PM Patricia Shanahan  wrote:

> I detangled the cables the hard way - shut everything down, unplugged,
> detangled, and put it back together with only the cables that are
> currently being used.
>
> Now I do need some advice. What is the best starting point for learning
> Git-for-AOO? I do have a GitHub account, with my personal e-mail address
> not my apache.org address.
>
> On 10/28/2019 11:33 AM, Patricia Shanahan wrote:
> > Thanks, but what I need is a magic wand of cable untangling I don't
> > suppose you have one handy.
> >
> > In installing my new computer I found that the cables connecting various
> > computers, displays, router, and printer are a mess.
> >
> > On 10/28/2019 9:51 AM, Matthias Seidel wrote:
> >> Hi Patricia,
> >>
> >> How are things going?
> >> If you are in need of something just let me know...
> >>
> >> Regards,
> >>
> >> Matthias
> >>
> >> Am 26.10.19 um 06:24 schrieb Patricia Shanahan:
> >>> Any opinions on which I should do?
> >>>
> >>>
> >>> On 10/25/2019 1:27 PM, Matthias Seidel wrote:
>  Hi Patricia,
> 
>  If you want to build 4.1.x have a look at:
>  https://home.apache.org/~mseidel/AOO-builds/AOO-418-Test/ReadMe.txt
> 
>  For 4.2.x (and trunk) see:
>  https://home.apache.org/~mseidel/AOO-builds/AOO-420-Test/ReadMe.txt
> 
>  This is how I do my test builds.
> 
>  Regards,
> 
>   Matthias
> 
>  Am 24.10.19 um 22:09 schrieb Patricia Shanahan:
> > Are the Windows 10 instructions up-to-date?
> >
> > I have just got a shiny new Windows 10 Pro computer, and am planning
> a
> > clean start on AOO building. It will take a day or so for me to
> > install and set up basic stuff, and then I'll need to install
> whatever
> > I need for AOO building.
> >
> > -
> > 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
> >>>
> >>>
> >>
> >
>
> --
> This email has been checked for viruses by AVG.
> https://www.avg.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: [DISCUSSION] Build environment future

2019-10-30 Thread Jim Jagielski 
Is the build environment really enough of a failure that we need to spend time 
on redoing it again?

Now if people want to work on that, I'm fine... we are all volunteers and work 
on stuff that interests us, but certainly, if people are *looking* for things 
to do, improving the actual code itself might be more worthwhile that 
rejiggering the build setup.

> On Oct 30, 2019, at 1:25 AM, Peter Kovacs  wrote:
> 
> Hello Damjan and all
> 
> 
> I would like to re-discuss our current plan. Hoping to gain a common view.
> 
> Current state is mostly we use gmake, there are still some difficult to
> migrate dmake projects. And we use Ant for java.
> 
> The plan is not to stop at the dmake -> gmake conversion but to move on
> to scons, removing as much dependencies as we can. Right?
> 
> I would like to set the target to build everything to Ant, removing as
> much dependencies we can.
> 
> 
> My arguments are mostly that Ant is supported by most when not all IDEs
> and I would really like to have an IDE as working environment, and my
> hope is that it is easier maybe to integrate an Ant build environment
> then a scons or gmake environment.
> 
>  I think this would give us a better base then the plan above. So what
> was the arguments against Ant again?
> 
> 
> All the Best
> 
> Peter
> 
> 
> -
> 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

Re: [DISCUSSION] Build environment future

2019-10-30 Thread Branko Čibej 
On 30.10.2019 06:25, Peter Kovacs wrote:
> Hello Damjan and all
>
>
> I would like to re-discuss our current plan. Hoping to gain a common view.
>
> Current state is mostly we use gmake, there are still some difficult to
> migrate dmake projects. And we use Ant for java.
>
> The plan is not to stop at the dmake -> gmake conversion but to move on
> to scons, removing as much dependencies as we can. Right?


As a far-too-long-time user of Scons (in Serf), let me just add a
caution: Scons is very, very broken and not at all well maintained.
Writing a truly cross-platform, cross-toolchain SConstruct file for
anything other than really trivial cases amounts to writing a *lot* of
platform-specific Python code to make the builds work.

If you're already moving to gmake (without autotools, and I expect using
Cygwin on Windows), then I suggest you finish the transition, then leave
well enough alone.

-- Brane

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

Re: New computer

2019-10-30 Thread Patricia Shanahan 
I detangled the cables the hard way - shut everything down, unplugged, 
detangled, and put it back together with only the cables that are 
currently being used.


Now I do need some advice. What is the best starting point for learning 
Git-for-AOO? I do have a GitHub account, with my personal e-mail address 
not my apache.org address.


On 10/28/2019 11:33 AM, Patricia Shanahan wrote:
Thanks, but what I need is a magic wand of cable untangling I don't 
suppose you have one handy.


In installing my new computer I found that the cables connecting various 
computers, displays, router, and printer are a mess.


On 10/28/2019 9:51 AM, Matthias Seidel wrote:

Hi Patricia,

How are things going?
If you are in need of something just let me know...

Regards,

    Matthias

Am 26.10.19 um 06:24 schrieb Patricia Shanahan:

Any opinions on which I should do?


On 10/25/2019 1:27 PM, Matthias Seidel wrote:

Hi Patricia,

If you want to build 4.1.x have a look at:
https://home.apache.org/~mseidel/AOO-builds/AOO-418-Test/ReadMe.txt

For 4.2.x (and trunk) see:
https://home.apache.org/~mseidel/AOO-builds/AOO-420-Test/ReadMe.txt

This is how I do my test builds.

Regards,

 Matthias

Am 24.10.19 um 22:09 schrieb Patricia Shanahan:

Are the Windows 10 instructions up-to-date?

I have just got a shiny new Windows 10 Pro computer, and am planning a
clean start on AOO building. It will take a day or so for me to
install and set up basic stuff, and then I'll need to install whatever
I need for AOO building.

-
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








--
This email has been checked for viruses by AVG.
https://www.avg.com


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

Re: [DISCUSSION] Build environment future

2019-10-30 Thread Patricia Shanahan 
As a user of the build system, I think we have too many build 
strategies, and should not add another one unless it is absolutely 
essential to do so. Of course I would prefer an IDE, but another round 
of build system changes is far too high a price to pay.


Given that most is on gmake, I would much prefer to stick with gmake.

If we keep changing our collective mind about the build system we will 
never have a consistent system, but will always have some modules on 
each of several systems.


On 10/29/2019 10:25 PM, Peter Kovacs wrote:

Hello Damjan and all


I would like to re-discuss our current plan. Hoping to gain a common view.

Current state is mostly we use gmake, there are still some difficult to
migrate dmake projects. And we use Ant for java.

The plan is not to stop at the dmake -> gmake conversion but to move on
to scons, removing as much dependencies as we can. Right?

I would like to set the target to build everything to Ant, removing as
much dependencies we can.


My arguments are mostly that Ant is supported by most when not all IDEs
and I would really like to have an IDE as working environment, and my
hope is that it is easier maybe to integrate an Ant build environment
then a scons or gmake environment.

  I think this would give us a better base then the plan above. So what
was the arguments against Ant again?


All the Best

Peter


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



--
This email has been checked for viruses by AVG.
https://www.avg.com


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

Re: [DISCUSSION] Build environment future

2019-10-30 Thread Mechtilde 
Hello Peter and all,

Am 30.10.19 um 06:25 schrieb Peter Kovacs:
> Hello Damjan and all
> 
> 
> I would like to re-discuss our current plan. Hoping to gain a common view.
> 
> Current state is mostly we use gmake, there are still some difficult to
> migrate dmake projects. And we use Ant for java.

Are gmake or rather dmake only for building with Java? and scons?
> 
> The plan is not to stop at the dmake -> gmake conversion but to move on
> to scons, removing as much dependencies as we can. Right?

For building on Linux IMO it is easier to remove the shipped
dependencies because there are also part of the distributions we build on.

But we need them for building on Windows, don't we.
> 
> I would like to set the target to build everything to Ant, removing as
> much dependencies we can.

What does everything means? only Java stuff? or also the C++ stuff?

> My arguments are mostly that Ant is supported by most when not all IDEs
> and I would really like to have an IDE as working environment, and my
> hopegma is that it is easier maybe to integrate an Ant build environment
> then a scons or gmake environment.
> 
>  I think this would give us a better base then the plan above. So what
> was the arguments against Ant again?

see my questions above
> 
> 
> All the Best
> 
> Peter

Kind regards

-- 
Mechtilde Stehmann
## Apache OpenOffice
## Freie Office Suite für Linux, MacOSX, Windows
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



signature.asc
Description: OpenPGP digital signature