Regarding the numbers that fixed my issue. Could you suggest a way to verify the validity of the fix? I tested it on 5-6 different workstations with different people having the same issue and the fix fully worked on all stations. I sincerely would like to get the fix reviewed from the code author or someone with knowledge in this are but I would need some help here to find out the right person to ask. Meanwhile. Any usage around this build that has been shared comes with no warranty. Use with sense.
fredag 5 maj 2023 kl. 17:23:48 UTC+2 skrev dudek53: > Hi. Hacking? Not really following what you mean. Heavy on the negativity > here. > I´ll remove the sources for now. They were published for users or others > to build upon. I have a hard time seeing a better way at this stage > documenting this but others are free to chime in. I keep my personal stuff > secluded from now on. > This work is mainly done from Erkan so I assume what he posted is as > unorthodox. Hopefully he´ll fullfill his work when he can according to the > "rules" and guidelines. > If anyone wants to play with my changes they can contact me and i´ll help > or share findings in that case. > Have a great weekend all. > /D > > fredag 5 maj 2023 kl. 17:05:09 UTC+2 skrev T. Modes: > >> dud...@gmail.com schrieb am Freitag, 5. Mai 2023 um 11:38:20 UTC+2: >> >> Added sources and diffed the arm64 hugin source against latest official >> sources here. Maybe helps to follow changes from Erkan and me: >> https://bitbucket.org/Dannephoto/hugin/src/master/ >> >> >> sorry, but it does not help. This is hacking that it works for *you* only >> and not for any other. >> >> Instead of cloning the existing repository you copied all files to a new >> git repo. Now the whole history is lost. Also it is unknown on which >> changeset it is based. >> >> Next, in one changeset you copied the files from the official hugin repo. >> In the next changeset you add your changes and at the same time you revert >> a lot of changes to an earlier changeset of the Hugin repo- which is also >> unknown. >> So the changeset is more complicated than necessary. It contains your >> changes and a lot of unrelated and unnecessary changes at the same time. >> This makes it very confusing to see your changes only. >> >> Hugins build system is connected with the mercurial repo. By switching to >> git you break this and need to add a file which is (intentional) not under >> revision control in mercurial. (There are special ways to handle the >> releases, but these should not be used in development in between.) >> >> Next your changes in the source code break the compilation on all other >> platforms -> "works for me" is not enough. The changes must not break >> compilation (and running) on other systems. >> >> Also randomly changing numbers and sign in the source code without >> understanding what you do only that it works in *your* single use case is >> not acceptable. I mentioned this already to you but you have ignored this. >> >> Also changing lines in the script and then commenting out the same line >> is a bad style and makes the diff more confuse than needed. >> >> Beside all these mentioned issue it would be recommend to split the >> changes into small chunks: e.g. one changeset with only changes to the >> build script, a second one with the needed code changes. >> >> Combined it is very difficult to review your changes because of all these >> mentioned points. >> Currently it can't applied to official repo because it breaks existing >> code. >> >> -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/e23c72ba-9242-4622-acde-163c72bc8839n%40googlegroups.com.
