Re: Compile Linux x86

2023-04-25 Thread Arrigo Marchiori
Hello Pedro,

On Sun, Apr 16, 2023 at 10:32:03AM +0100, Pedro Lino wrote:

> Hi all
>  
> This is very a basic question for a programmer but as "developer" I could not 
> find any clear documentation: how do I compile an x86 build in Linux?
>  
> I have managed to build an x64 Linux installer following the steps in
> https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO
> but
>  
> 1) When compiling on a physical PC (aka metal) do I need an x86 CPU to build 
> an x86 build?
>  
> if the answer to 1) is no then
>  
> 2) Do I need and x86 Linux OS?

For what it's worth, I am using a virtual machine, in which I
installed 32 bit Linux, for testing 32 bit builds. Our release builds
are done in VM's as well.

> if not then, how do I get shell script to setup an x86 environment? I can't 
> understand the instructions to create the LinuxX86Env.Set.sh script needed 
> for the unxlngi6 platform...

If you have an x86_64 Linux system (either bare metal or virtual,
should make no difference) you should be able to build for 32 bit by
forcing parameter "-m32" to the compiler.

It should be enough to instruct the configure script to use proper
CFLAGS and CXXFLAGS:

$ CFLAGS="-m32" CXXFLAGS="-m32" ./configure [other parameters]

I cannot confirm this will work, because the build system is very
complex, but that is how I would do for other software projects.

I hope this helps.

Best regards,
-- 
Arrigo

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



Re: Changes proposal for the future AOO 5.0.0

2023-04-25 Thread Arrigo Marchiori
Hello All,

replying mid-thread.

On Sat, Apr 22, 2023 at 04:41:37PM +0200, Corentin Verbrèghe wrote:

> Hello,
> I think that making my proposal an extension of AOO is a bad idea, I rather
> thought that it should be part of the software because the problem of an
> extension is that it does not install automatically. Moreover, this could
> improve the gallery to make it much more interesting and complete, with an
> almost infinite choice of images, illustrations, icons and even audio files
> available for everyone. The fact that it is not an extension will make AOO
> more interesting and useful compared to before and other software such as
> LibreOffice.

Let's not forget that extensions could be embedded within the official
installer.

Choosing between an extension and "something else" (a module?) is IMHO
a choice about how to _develop_ this.

By keeping a separate code base from the AOO main trunk, we could have
more focused development.

By using an extension, we would have the possibility to update that
``part of AOO'' without recompiling the full AOO distribution, during
the development.

I also expect that developing an extension will be easier than
learning how the AOO code is organized, what classes do what etc.  And
maybe we may not even need C++, but rather Basic, Python or other more
accessible programming languages.

I hope this makes sense, and I encourage anyone interested to start
reading this:
https://wiki.openoffice.org/wiki/Extensions_development

Best regards,
-- 
Arrigo

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



Re: Changes proposal for the future AOO 5.0.0

2023-04-25 Thread Matthias Seidel
Hi Arrigo,

Am 25.04.23 um 12:26 schrieb Arrigo Marchiori:
> Hello All,
>
> replying mid-thread.
>
> On Sat, Apr 22, 2023 at 04:41:37PM +0200, Corentin Verbrèghe wrote:
>
>> Hello,
>> I think that making my proposal an extension of AOO is a bad idea, I rather
>> thought that it should be part of the software because the problem of an
>> extension is that it does not install automatically. Moreover, this could
>> improve the gallery to make it much more interesting and complete, with an
>> almost infinite choice of images, illustrations, icons and even audio files
>> available for everyone. The fact that it is not an extension will make AOO
>> more interesting and useful compared to before and other software such as
>> LibreOffice.
> Let's not forget that extensions could be embedded within the official
> installer.
>
> Choosing between an extension and "something else" (a module?) is IMHO
> a choice about how to _develop_ this.
>
> By keeping a separate code base from the AOO main trunk, we could have
> more focused development.
>
> By using an extension, we would have the possibility to update that
> ``part of AOO'' without recompiling the full AOO distribution, during
> the development.
>
> I also expect that developing an extension will be easier than
> learning how the AOO code is organized, what classes do what etc.  And
> maybe we may not even need C++, but rather Basic, Python or other more
> accessible programming languages.

I second this!

The idea is not new, but unfortunately these extensions are not
maintained atm:

https://extensions.openoffice.org/en/project/openclipart-gallery

https://extensions.openoffice.org/en/project/wikimedia-commons-gallery

Regards,

   Matthias

>
> I hope this makes sense, and I encourage anyone interested to start
> reading this:
> https://wiki.openoffice.org/wiki/Extensions_development
>
> Best regards,



smime.p7s
Description: S/MIME Cryptographic Signature


[GitHub] [openoffice-project] christ opened a new pull request, #4: Migrating posts from Roller (INFRA-24222)

2023-04-25 Thread via GitHub


christ opened a new pull request, #4:
URL: https://github.com/apache/openoffice-project/pull/4

   Pulled 110 posts from Roller DB into markdown. This does not include media, 
that can be handled later.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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