Hello all,
There is a Gordian knot to be solved. Because of constant swapping
attention we have started a lot of tasks which are now a bit in conflict.
I am not sure if the strategy to update MSVC is the right one as a
starter. But that should not stop you Arrigo to continue. :)
However this is not the first attempt. Maybe this post helps [6]. Maybe
George Karalis would be open to help and share his experience too?
I would expect difficulties on a and B approach. Damjan who did most of
the work on gmake said [1]:
"We already took that [make gmake work] approach to its limit, and I
don't believe we can go much further. Most of gmake works by luck."
Which I read as that the gmake usage is very fragile. But I am not
really have any clue how the perl scripts are tied with the dmake that
call gmake.
The SCONs transition still looks promising. The last post from Damjan
is at [2] And the Branch is at [5]. Which would be my personal
favourite route.
However a rename of the variables can be don on linux by one
commandline. To my understanding we need only to change *.mk files.
Which I figure are 1648 files.
This should be possible with a find and sed combination, and we could
try to build a Linux version. If that works, we check Mac and then we
are pretty save to continue on Windows.
Still I would store the changes in an own branch until the update is done.
However I have a hard time to believe that conflict is something new.
But I am not sure since one discussion on MSVC hints that
standardization was more then sad in the past. [3] Maybe I am wrong.
So maybe it is worth to have a quick glance at [4] if there the same
Issue apears. But not to much since the branch is old. I thought we had
a 64 bit conversion repository. But I am not sure where that went to.
If we start messing with the overall Windows build how do we proceed
with the work on Win64? Sadly I am not sure where Damjan put the 64 bit
conversion and where his last email has been to this point.
Puh what a topic mess. But Still I hope it helps you Arrigo to go
forward. I am in support on any approach.
All the best
Peter
[1]
https://lists.apache.org/thread.html/rceb42d4f390f88e5c63875a4670a850186513400668a12772ec2f6d5%40%3Cdev.openoffice.apache.org%3E
[2]
https://lists.apache.org/thread.html/r911b40a582019f641e93253df07341370cb9aeb9d1dc50474e48aa09%40%3Cdev.openoffice.apache.org%3E
[3]
https://lists.apache.org/thread.html/95db92e73a2ac7c0417016f74fbe30185b91069f379df2c77928cad8%40%3Cdev.openoffice.apache.org%3E
[4] https://github.com/apache/openoffice/tree/win8build
[5] https://github.com/apache/openoffice/tree/scons-build
[6]
https://lists.apache.org/thread.html/fcbeb2d29f1ca1116b22e410a2154c97cfe43a21f77d4fe3cd4d73b4%40%3Cdev.openoffice.apache.org%3E
On 15.05.21 08:57, Marcus wrote:
Am 14.05.21 um 21:56 schrieb Arrigo Marchiori:
I would go for option A- because option B- would lead to _very_ long
command lines and I would expect problems.
But would I stomp on anyone's feet if I did that? Would it be bad
practice? Would it violate any standards?
I am open to suggestions and criticism. Please let me hear your
opinion!
I'm not a core developer, so I don't know the details. However,
renaming such essential keywords like "INCLUDE" and "LIB" is indeed a
heavy change.
IMHO it's the same like switching the build system to gmake, scons or
whatever. It has to be done very carefully and would be an enormous
obstacle for us. There are f...cking many makefiles that need to be
changed. We have tried to change the build system more than one time
and both were not done until the end.
So, now we have a mix of 3-4 build systems inside the code. With a mix
of renamed keywords it won't get easier to maintain the code and even
not for new vontuneers to understand this.
What is currently used for building on Windows?
Any (good) need to chnge thisto VS 2015?
Who should do this change and is there a guarantee that the person is
doing it until the end?
Is it for sure that this is only influencing how we can build on
Windows or has it any side effects on the other platforms? If so,
renaming is more than a normal obstacle.
We need to discuss and decide this very detailed and carefully.
Sorry for these strong words and questions. However, my gut feeling
says "this is not a good idea".
My 2 ct.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
This is the Way! http://www.apache.org/theapacheway/index.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
