-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
base: master
Are you sure you want to change the base?
Remove binaries #4804
Conversation
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
…o remove-binaries
Would love to take a look at this branch before this is merged.
Thanks!!
Theo
|
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. I see #1805 for the removing binary part |
i remember discussing this structure on an irc meeting but don't think we ever created an issue |
So the folder structure would look like:
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 For the libs moving out of the repo how would that work with the core addons? One thing that I think will be really important for people contributing to OF is a really easy way to:
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. |
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 |
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 |
Exciting improvements guys! This is exactly what we need!! |
@arturoc @ofTheo Just going over the proposed repo changes. So oF will have:
This also paves the way to properly clear out the repo history of binaries, correct? |
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. |
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. |
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 --
or :
which looks like this:
so clean :) |
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:
expanded to
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 |
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 ? |
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 |
That last folder structure makes a lot of sense to me. Like that we're getting closer to how other libraries are structured. |
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