Make WordPress Core

Opened 11 years ago

Last modified 5 years ago

#25117 reopened feature request

The distribution build process should be fully available to anyone.

Reported by: mark-k's profile mark-k Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Build/Test Tools Keywords: has-patch needs-testing needs-refresh
Focuses: Cc:

Description

The wordress build environment for each version should be specified in enough detail for third parties to be able to run a build process and get the same distribution as generated by wordress.org.

See discussion about maintaining and documenting the build environment in #24977

Attachments (2)

25117.diff (1.9 KB) - added by nacin 10 years ago.
25117.2.diff (2.6 KB) - added by netweb 10 years ago.

Download all attachments as: .zip

Change History (18)

#1 @nacin
11 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #24976.

#2 @SergeyBiryukov
11 years ago

  • Summary changed from The distrebution build process should be fully available to anyone. to The distribution build process should be fully available to anyone.

#3 @mark-k
10 years ago

  • Resolution duplicate deleted
  • Status changed from closed to reopened

Reopening since #24976 was closed without providing the documentation requested here. and now we have the important automatic ltr to rtl conversion getting ready for 3.8.

Without the documentation on setting up the build environment, it will be hard for people to suggest patches for fixing rtl problem as they will have to run the build process to test them.

Yes, me and others can probably figure out what is required, but this info already exists with the core developers and I see no reason to make other people guess what is needed to be done.

Last edited 5 years ago by SergeyBiryukov (previous) (diff)

#4 @SergeyBiryukov
10 years ago

  • Milestone set to 3.8

#5 @SergeyBiryukov
10 years ago

  • Component changed from General to Build Tools

#6 @dd32
10 years ago

Reopening since #24076 was closed without providing the documentation requested here. and now we have the important automatic ltr to rtl conversion getting ready for 3.8.

To be clear, you want documentation on how to convert the src to build directory via our development tools (Grunt), and not how to build a release package (a zip file) like is distributed on WordPress.org (which is what was originally thought was being asked for by a few people)?

It doesn't look like we have a grunt section in the Core Contribution Handbook yet.

The basic process is, a) Install Node.JS locally b) Install the Grunt package c) Run Grunt's setup process for the WordPress directory, d) Run grunt build in the WordPress directory. I do agree that needs to be documented better though, I'm just including it here as a tip for others searching until proper documentation is written.

#7 @kpdesign
10 years ago

A new section is going to be added soon to the Core Contributor Handbook that explains the new build environment and how to set it up.

#8 @nacin
10 years ago

  1. http://nodejs.org/download/
  2. Run this:
    npm install -g grunt-cli
    
  3. In the directory of your SVN checkout of develop.svn.wordpress.org/trunk, run:
    $ npm install
    $ grunt
    

After this, just run grunt. (This is synonymous with grunt build.) You can also run grunt rtl which will generate the uncompressed RTL CSS for you.

npm install only needs to be done once, and then whenever new dependencies are added. grunt commands will fail when it is time to run npm install.

In addition to the handbook, a README file should be added to the root of develop.svn.wordpress.org/trunk.

Or: Check out http://core.svn.wordpress.org/trunk and patch that. If you patch a generated RTL file, someone will help you turn that into a patch for the corresponding LTR file. Honestly, especially for RTL, reporting bugs (and snippets of CSS, if possible) is far more useful than the patch anyway.

#9 @mark-k
10 years ago

@dd32, sorry I wasn't truly consistent but for me the practical difference is nil. you need to know what tools are used in the build process of the version being developed, and what switches are used to run them if any, and then you just maintain it for the non current versions.

@nacin. so I can't use the tools on ubuntu nor on windows? ;)
Anyway, a blanket statement about installing the latest software from a repository is wrong. Today it will give me version 0.10 and tomorrow it will be 0.11. are there any guaranties that 0.11 will be fully backward compatible to 0.10 and the build script will not break in it?

Or: Check out ​http://core.svn.wordpress.org/trunk and patch that. If you patch a generated RTL file, someone will help you turn that into a patch for the corresponding LTR file

This will create a bottleneck of experts that will have to spend time generating and testing patches that other people could have submitted. This will escalate the more build tools are being used (LESS for example).

About the README - if it can not be indexed by google then it is not useful as no one reads documentation and when people do need documentation they turn to google and not starting to look for readme files.

#10 @nacin
10 years ago

You can use the tools on any operating system. Node is available for Windows, Linux, Mac, etc. Yes, just install the latest. npm is a package manager that will handle dependencies of the various other pieces of software (grunt, various node libraries, and various grunt libraries).

This will create a bottleneck of experts that will have to spend time generating and testing patches that other people could have submitted.

Maybe. Or maybe those people will continue to submit patches. Any new tooling will *always* increase the barrier to entry somewhat, but the benefits far outweigh the costs. In the case of RTL, this was calculated risk. We have never had a whole lot of RTL tickets open at any given time, and still don't. http://core.trac.wordpress.org/query?component=RTL&status=!closed. But this makes future development easier.

I'm not saying it will only be a readme. I'm saying there will also be a readme.

#11 @samuelsidler
10 years ago

  • Milestone changed from 3.8 to WordPress.org

@nacin
10 years ago

@netweb
10 years ago

#12 @netweb
10 years ago

  • Keywords has-patch added

In 25117.2.diff is the same as 25117.diff with the only change being the inclusion of index.php in each of the /wp-content, /wp-content/plugins and /wp-content/themes folders for the package archives that include /wp-content.

Edit: Patch also includes updates svn:ignore and .gitignore to ignore the /packages folder.
Sidenote: The patch also displays the svn:ignore property change inline with the .gitignore file, a tweak to the Trac configuration should fix this, "whatever" that may be.


I've also pinged @samuelsidler about adding "Build Tools" to the Core Handbook as this is still needed.
http://make.wordpress.org/core/handbook/

I have a good start of this for bbPress already done, copy, paste, and update and we'll get it up soonish.
https://github.com/ntwb/bbPress/blob/master/README.md

Last edited 10 years ago by netweb (previous) (diff)

This ticket was mentioned in IRC in #wordpress-dev by netweb. View the logs.


9 years ago

#14 @jorbin
9 years ago

  • Milestone changed from WordPress.org to 4.1

The handbook page is another piece of this, but getting the package task added will help increase our transparency.

#15 @ocean90
9 years ago

  • Milestone changed from 4.1 to Future Release

#16 @chriscct7
8 years ago

  • Keywords needs-testing needs-refresh added
Note: See TracTickets for help on using tickets.