Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • P purr-data
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 363
    • Issues 363
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 54
    • Merge requests 54
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Jonathan Wilkes
  • purr-data
  • Issues
  • #236

Closed
Open
Created Jan 28, 2017 by Jonathan Wilkes@jwilkesOwner

humans cannot reason about our build system

  1. Try to fix what should be a trivial problem with an out-of-date package name causing issues in the OSX build
  2. Get stumped
  3. Ask for help, get sage advice
  4. Remain stumped
  5. Accept perfectly reasonable, well documented merge request that fixes the issue.
  6. End up with two new bugs

Granted, one of those bugs would have been caught if there was a Windows VM as part of the automated builds. But the other one was subtle and in a class for which our build tools provide us absolutely no help whatsoever.

However, we're stuck with our recursive Gnu makefile system. There is no other battle-tested, sane build system that provides a significant usability increase to offset the cost of changing build systems. So, here is a tentative path toward less future pain:

  • Remove old "cloud storage" from the repo. First, find every purr-data/external lib not listed in LIB_TARGETS which doesn't target all supported platforms, then remove them and erased themfrom externals/Makefile. Then do the same for dead externals which aren't in the libdir format. Finally, remove the dead externals that are in libdir format. This should leave us with one big knot remaining-- "miXed", which contains cyclone. But that can be addressed as we port to Alexandre's version at a later time.
  • Merge doc/pddp into pd/doc/5.reference and make necessary adjustments in Makefiles. Later, maybe even merge doc into pd/doc, but that might not be necessary
  • when we are ready to bump Gem to a more recent version, move Gem to externals/Gem
  • when we are ready to bump Gem, figure out why Gem is autogen'ing all its cruft during make clean and don't do that
  • figure out if videoIO is used-- if it is not, then nuke it
  • merge everything except K12 stuff from l2ork_addons into wherever it belongs in the repo. This will require porting disis_munger~, putting spectdelay into externals/ (plus making sure it compiles on all platforms), eventually moving tar_em_up.sh to toplevel dir.
  • remove flext from the repo
  • merge debbuild and packages/linux_make
  • figure out if packages/patches is used. if not, nuke it
  • find remaining tcl/tk build targets, scripts, etc., and remove them from the repo

Probably a lot else, but that's at least a start.

Also, this is a very tentative list written in haste and can be changed at will. The point is essentially to not have a zillion lines of dead script/code/doc getting in the way of potential devs. And especially to not have multiple contradictory versions of the same doc/code waiting for people to confuse.

The build system will still be bad, but at least no one will waste time looking at the wrong bad parts. :)

Assignee
Assign to
Time tracking