For organizational reasons and to make it easier for other developers to build UXP applications, we need to split our applications out into separate repositories and set the build system up to do a comm-like build where application code is application code, and the platform is pulled in as a submodule.
Advantages:
Clear separation of applications (releases/etc.)
Independent development possible on arbitrary back-end commits
Clarity about the platform/application structure for the platform
Separation of application-specific issues that aren’t necessarily relevant for the platform, and v.v.
Uniform build procedure for all UXP applications
Disadvantages:
Some issues that impact both FE and BE will have to be split, with FE patches including a branch pointer shift.
This should be tackled later in 2019, probably Q4.
For organizational reasons and to make it easier for other developers to build UXP applications, we need to split our applications out into separate repositories and set the build system up to do a comm-like build where application code is application code, and the platform is pulled in as a submodule.
Advantages:
- Clear separation of applications (releases/etc.)
- Independent development possible on arbitrary back-end commits
- Clarity about the platform/application structure for the platform
- Separation of application-specific issues that aren't necessarily relevant for the platform, and v.v.
- Uniform build procedure for all UXP applications
Disadvantages:
- Some issues that impact both FE and BE will have to be split, with FE patches including a branch pointer shift.
This should be tackled later in 2019, probably Q4.
As per IM discussion that took place but wasn’t documented: post commization of the MCP Phoenix-class browsers will result in an official stable release branch being established for Pale Moon.
This will allow for Pale Moon and those other applications that match platform states with Pale Moon to easily target a consistant release state for comparative and debug reasons. BinOC projects will also follow this branch for release.
Basilisk being rolling will likely use trunk at arbitrary stable luls between major development cycles.
Individual projects will decide their own commit points of the platform. The current hacks that allow the application subdirectory to work will be kept for those that already use it.
The tl;dr of this decision should help estabilish UXP’s independence as a cross-project/cross-organization/cross-community software platform in and of its self without being encumbered by any one specific project.
As per IM discussion that took place but wasn't documented: post commization of the MCP Phoenix-class browsers will result in an official stable release branch being established for Pale Moon.
This will allow for Pale Moon and those other applications that match platform states with Pale Moon to easily target a consistant release state for comparative and debug reasons. BinOC projects will also follow this branch for release.
Basilisk being rolling will likely use trunk at arbitrary stable luls between major development cycles.
Individual projects will decide their own commit points of the platform. The current hacks that allow the application subdirectory to work will be kept for those that already use it.
The tl;dr of this decision should help estabilish UXP's independence as a cross-project/cross-organization/cross-community software platform in and of its self without being encumbered by any one specific project.
You are building win32 or you are building ON win32? Also, those paths don’t make any sense and it is out of context. Though I am doing a win32 build now.
You are building win32 or you are building ON win32? Also, those paths don't make any sense and it is out of context. Though I am doing a win32 build now.
win32 target on win64 host, the path above is only one that has no platform included, it should be -Id:/Pale-Moon/platform/layout/style like all others.
win32 target on win64 host, the path above is only one that has no `platform` included, it should be `-Id:/Pale-Moon/platform/layout/style` like all others.
Yeah.. and I don’t understand why.. IF this was something specifically to do with the comm-configuration then Borealis and Interlink as well as the Hyperbola applications would ALSO fail.
As I said, I am doing a win32 build right now.
Yeah.. and I don't understand why.. IF this was something specifically to do with the comm-configuration then Borealis and Interlink as well as the Hyperbola applications would ALSO fail.
As I said, I am doing a win32 build right now.
I’m sorry, but it’s 2:50am local time, I’ll provide all you requested in about 10 hours, as it’s really hard to collect it right now using vnc session from my tablet.
I'm sorry, but it's 2:50am local time, I'll provide all you requested in about 10 hours, as it's really hard to collect it right now using vnc session from my tablet.
Not entirely sure why you immediately jumped on building this when stuff is still being organized and in-progress :)
Anyway, just provide when you’re awake again; I’m sure it’s something like setting the MOZ_OBJDIR to an absolute path or something.
Not entirely sure why you immediately jumped on building this when stuff is still being organized and in-progress :)
Anyway, just provide when you're awake again; I'm sure it's something like setting the MOZ_OBJDIR to an absolute path or something.
I had to manually purge all the *.pyc files (some of them were even from 2017), and now everything builds properly. Apparently, this because I continued to work in the old PM repo.
It seems I really shouldn’t have to build at night, sorry for the noise.
I had to manually purge all the `*.pyc` files (some of them were even from 2017), and now everything builds properly. Apparently, this because I continued to work in the old PM repo.
It seems I really shouldn't have to build at night, sorry for the noise.
For organizational reasons and to make it easier for other developers to build UXP applications, we need to split our applications out into separate repositories and set the build system up to do a comm-like build where application code is application code, and the platform is pulled in as a submodule.
Advantages:
Disadvantages:
This should be tackled later in 2019, probably Q4.
As per IM discussion that took place but wasn’t documented: post commization of the MCP Phoenix-class browsers will result in an official stable release branch being established for Pale Moon.
This will allow for Pale Moon and those other applications that match platform states with Pale Moon to easily target a consistant release state for comparative and debug reasons. BinOC projects will also follow this branch for release.
Basilisk being rolling will likely use trunk at arbitrary stable luls between major development cycles.
Individual projects will decide their own commit points of the platform. The current hacks that allow the application subdirectory to work will be kept for those that already use it.
The tl;dr of this decision should help estabilish UXP’s independence as a cross-project/cross-organization/cross-community software platform in and of its self without being encumbered by any one specific project.
Pale Moon has been returned back to its original repository.
Depends on https://github.com/MoonchildProductions/Pale-Moon/issues/1697
I have a problem building on win32:
It seems this path is wrong:
-Id:/Pale-Moon/layout/style
You are building win32 or you are building ON win32? Also, those paths don’t make any sense and it is out of context. Though I am doing a win32 build now.
win32 target on win64 host, the path above is only one that has no
platform
included, it should be-Id:/Pale-Moon/platform/layout/style
like all others.Yeah.. and I don’t understand why.. IF this was something specifically to do with the comm-configuration then Borealis and Interlink as well as the Hyperbola applications would ALSO fail.
As I said, I am doing a win32 build right now.
Is that objdir reused?
Clobber build is failed exactly the same way.
What is your directory structure and what is your
mozconfig
and get meconfig.status
I’m sorry, but it’s 2:50am local time, I’ll provide all you requested in about 10 hours, as it’s really hard to collect it right now using vnc session from my tablet.
Not entirely sure why you immediately jumped on building this when stuff is still being organized and in-progress :)
Anyway, just provide when you’re awake again; I’m sure it’s something like setting the MOZ_OBJDIR to an absolute path or something.
I had to manually purge all the
*.pyc
files (some of them were even from 2017), and now everything builds properly. Apparently, this because I continued to work in the old PM repo.It seems I really shouldn’t have to build at night, sorry for the noise.
Well it is good to know of that case so if someone runs into it we have an answer.
Mac build is currently busted. Fix is this:
https://pastebin.com/raw/BLWHe4jR
@mattatobin This is same as mentioned on IRC.
Why did you respond here and not issue a pull request?
Sorry I commented on the wrong issue. I had to go through extra work to set up the new repo, but now you have a PR. Be happy!
I am :)
Basilisk is now switched to its new repository at https://github.com/MoonchildProductions/Basilisk