Skip to content

Remove binaries #4804

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Conversation

arturoc
Copy link
Member

@arturoc arturoc commented Feb 10, 2016

removes all binaries that will be generated through travis and appveyor
in the apothecary repository

libs will be included later as a subrepo so we need to move the OF
code and projects out of that folder.

the OF code now lives in /src
libs/openFrameworksCompiled/project -> /projects
libs/openFrameworksCompiled/lib -> /build

This requires some changes to the project files, makefiles and qtcreator
in linux are tested and working but the rest of the platforms still need
some work

removes all binaries that will be generated through travis and appveyor
in the apothecary repository

libs will be included later as a subrepo so we need to move the OF
code and projects out of that folder.

the OF code now lives in /src
libs/openFrameworksCompiled/project -> /projects
libs/openFrameworksCompiled/lib -> /build

This requires some changes to the project files, makefiles and qtcreator
in linux are tested and working but the rest of the platforms still need
some work
@ofTheo
Copy link
Member

ofTheo commented Feb 10, 2016 via email

@ofTheo
Copy link
Member

ofTheo commented Feb 10, 2016

oh nice ( was hard to read those path changes on mobile )

I like that we're standardizing it a bit more to how most libraries are structured.
was there an issue where the new paths were discussed?

I see #1805 for the removing binary part

@arturoc
Copy link
Member Author

arturoc commented Feb 10, 2016

i remember discussing this structure on an irc meeting but don't think we ever created an issue

@ofTheo
Copy link
Member

ofTheo commented Feb 10, 2016

So the folder structure would look like:

 addons/
 apps/
 build/
 docs/
 examples/
 export/
 libs/ <-- submodule
 other/
 projectGenerator/
 projects/ <-- projects for building the OF lib
 scripts/
 src/ <-- where OF src is now 
 tests/

I wonder if we are restructuring things if it would make sense to move the template files for the project generator out of the scripts/ directory - it always seemed a bit weird to me that they were located there?

Maybe they could live at projects/templates/?

For the libs moving out of the repo how would that work with the core addons?
Would we just have OpenCv and Assimp in the libs folder and then reference them from the addon that way? or a subfolder inside of libs/addons ?

One thing that I think will be really important for people contributing to OF is a really easy way to:

  • Pull down the libs
  • Generate project files for the examples

The more we break things into submodules the slower it will be to get people up and running and the more issues people will have related to submodules - so some sort of RunMe.sh to pull in everything needed to build and test OF would be really key.

@arturoc
Copy link
Member Author

arturoc commented Feb 10, 2016

yes i haven't figured out the addons yet. right now i'm setting a repo that will build the libraries on the tests servers so once that's working one possibility would be to have a script that downloads those libraries from our servers and puts them in the right places without having to run apothecary

@arturoc
Copy link
Member Author

arturoc commented Feb 10, 2016

and yes that's the structure, not sure about the templates, it might make sense. really don't have a strong preference for one or the other

@danoli3
Copy link
Member

danoli3 commented Feb 15, 2016

Exciting improvements guys! This is exactly what we need!!

@danoli3
Copy link
Member

danoli3 commented Feb 15, 2016

@arturoc @ofTheo Just going over the proposed repo changes. So oF will have:

  • openFrameworks/openFrameworks - As is with the above modifications
  • openFrameworks/apothecary - For the formulas / build scripts (submodule)
  • openFrameworks/openFrameworksLibraries - For the Dependancy / Libraries (submodule)
  • openFrameworks/projectgenerator - Project Generator (submodule)

This also paves the way to properly clear out the repo history of binaries, correct?

@ofZach
Copy link
Contributor

ofZach commented Feb 15, 2016

I wonder if there is a name like "recipes" instead of projects? I find it a little confusing to have projects/examples/apps at the root level. projects seems to signify something you'd be working in.

@arturoc
Copy link
Member Author

arturoc commented Feb 15, 2016

mmh, yeah makes sense, projects is pretty standard but i see how it can be confusing, but recipes sounds to me like it referred to apothecary for some reason. this folder contains the project files for the OF library mostly and we can move the project templates for examples and apps in there too.

@ofZach
Copy link
Contributor

ofZach commented Feb 15, 2016

also I think organizing folders as much as possible will be helpful to consider, I'm not sure what we can consolidate but I think the less we have the root level (and clearer they are) the better --

 addons/
 apps/
 build/
 docs/
 examples/
 3rdParty/export
 3rdParty/libs
 projectGenerator/
 recipes/projects/ <-- projects for building the OF lib
 recipes/scripts/
 src/ <-- where OF src is now 
 tests/

or :

 addons/
 apps/
 docs/
 examples/
 3rdParty/export
 3rdParty/libs
 projectGenerator/
 openFrameworks/build
 openFrameworks/projects/ <-- projects for building the OF lib
 openFrameworks/scripts/
 openFrameworks/src/ <-- where OF src is now 
 tests/

which looks like this:

 addons/
 apps/
 docs/
 examples/
 3rdParty/
 projectGenerator/
 openFrameworks/
 tests/

so clean :)

@arturoc
Copy link
Member Author

arturoc commented Feb 15, 2016

having the source in an src folder in the root is pretty standard, i'd really like to have it like that.

export should go away i think we only have libraries there that are already somewhere else we should just take them from there. that way 3rdParty (the capitalization looks weird :) could go away and we still keep libs.

projects can perhaps be inside build?

the main advantage of this structure is that we still libs in the root folder and the same level of hierarchy for libraries, if we add a couple of soft links in libs from openFrameworks -> ../src and openFrameworksCompiled -> ../build/ old projects will keep working which is a great advantage i think

the root would look like:

 addons/
 apps/
 docs/
 examples/
 libs/
 build/
 projectGenerator/
 src/
 tests/
 scripts/

expanded to

 addons/
 apps/
 docs/
 examples/
 libs/
  |_...
  |_openFrameworks -> ../src
  |_openFrameworksCompiled -> ../build
 build/
  |_project
  |_lib
  |_templates?
 projectGenerator/
  |_templates?
 src/
 tests/
 scripts/

i think this resambles what is the standard for lots of open source libraries and doesn't invalidate install procedures (scripts still in root) so any reference about how to install stuff will still work which i think is important

@ofZach
Copy link
Contributor

ofZach commented Feb 15, 2016

that sounds good to me, I got a little worried seeing so many folders at the root level but this seems pretty reasonable. Looking at this, maybe templates belong in PG ?

@arturoc
Copy link
Member Author

arturoc commented Feb 15, 2016

yeah i'm not completely sure about that because at some point templates could also be used by other tools like the IDE plugins and having the in the PG folder would add a dependency on those tools to the PG instead of only requiring OF. don't think it's such a big deal either since the PG will be always in the download and it's relatively easy to get when using github but something to take into consideration too

@ofTheo
Copy link
Member

ofTheo commented Feb 15, 2016

That last folder structure makes a lot of sense to me. Like that we're getting closer to how other libraries are structured.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants