support for main.cpp-only projects

[kylemcdonald]

a lot of projects i post, e.g. https://github.com/kylemcdonald/openFrameworksDemos/ only come with a main.cpp and no ofApp.cpp or ofApp.h. but the project generator tries to add these files anyway, and this causes compilation problems.

[ofZach]

this actually isn't in the PG but in the OSX template (and in all the templates, to be honest). I don't know what the best solution is here -- maybe remove all src files from the templates and add them when scanning src (or generating a new project....)

[kylemcdonald]

oh interesting! well my vote is to making the template main.cpp-only :) and then the PG would support legacy testApp projects, ofApp projects, and main.cpp-only projects.

[ofZach]

seems like a good solution, curious if this impacts at all the makefile system or any of the other wizards (cc @arturoc @admsyn). I need to take a look at how templates get parsed and / or how to include those ofApp.cpp / ofApp.h files on new projects.

also, to remind myself and others, looks like some relevant lines here:
https://github.com/openframeworks/projectGenerator/blob/master/ofxProjectGenerator/src/projects/baseProject.cpp#L166-L171

[arturoc]

i think we should keep ofApp.cpp/.h and include them by default, if the project is being updated then don't add them if the src folder already exists.

we should also create a template for apps with main.cpp only for quick examples... but i think in general having .h is a good practive because it shows people that if they want to create their own classes they need to have both. otherwise it would be confusing to understand why the default is to have cpp alone but for your own classes you need to create .h

the makefiles already work if you have main.cpp alone

also for the templates with 1 cpp file only i would name that file ofApp.cpp rather than main.cpp

[kylemcdonald]

also for the templates with 1 cpp file only i would name that file ofApp.cpp rather than main.cpp

interesting, i hadn't even considered this before. i'll switch to this :)

what if all the project template and all they examples had ofApp.cpp and main.cpp combined? i guess the downside would be that people might not make the conceptual leap to having multiple ofBaseApp-derived classes, so maybe this isn't a good idea.

[ofZach]

also, note that the PG gui doesn't expose the templates at this point, and on the command line PG side, only create and single update use the template parameter, but recursive update does not. I think it could be made to do so -- It would be interesting to consider if the template for a given project could be written into a file similar to "addons.make", which would make recursive updating a little smoother for a folder of projects made with different templates.

this is how you list the templates from the command line tool (you might need to chand the OF path...)

 ./projectGenerator --listtemplates -o"../../../../" -p"osx"

to use a template:

 ./projectGenerator -t"nowindow" -o"../../../../"  -p"osx" pathToProjectToBeUpdated

where pathToProjectToBeUpdated is an existing project (or even a name of a new project).

right now the print out for the list templates looks a little weird to me (it's mostly ok, but the name of the template is missing)

hopefully these command line approaches will help for experimenting with templates....

[arturoc]

the templates have a metadata file, by now they only have the description, supported platform and a simple renaming of files with:

RENAME=somefile.ext ${PROJECTNAME}.ext

but we could add more info like if the template is a main template in which case it'll overwrite everything it contains, including the folder (only if you are creating a project not updating)

or some other mechanism to have templates for different types of projects.

we could also have templates for addons for example in which the PG (or the IDE plugins ) would create a project with the structure of an addon with an example

[ofZach]

I guess what I mean is something like having a template section in config.make or a seperate file like addons.make so that you can parse out the template from a given project -- in kyles case, he could label these projects as "mainOnly" or "singleCpp" or whatever his template is called, so when he uses update recursively it does the right thing at a per project level.

addons.make works fairly well now as a lightweight read / write settings file per project, maybe something similar...

[arturoc]

mmh, yes that might be useful for other stuff like the nofmod template or similar where it has to know which project file to generate but i think the source files shouldn't be touched once the src folder is there that would solve a lot of this issues in an easy way, not only projects with main.cpp but also old examples using testApp.h or people changing their ofApp.cpp/h to their own custom name where the PG also fails

[memo]

I just encountered this problem too, I use single .cpp for examples (and even my own projects), but I usually don't use the same name (main.cpp or ofApp.cpp), but instead use a more descriptive name, so that if I have a dozen projects open, I don't have a dozen tabs all with main.cpp, but something meaningful. e.g.
https://github.com/memo/ofxMSAOrderedMap/tree/master/example-orderedmap/src
https://github.com/memo/ofxMSAOrderedPointerMap/tree/master/example-orderedpointermap/src
https://github.com/memo/ofxMSAmcts/tree/master/example_oxo/src
https://github.com/memo/ofxMSAmcts/tree/master/example_circle/src
(I notice the inconsistency with - and _, argh, killing me)

I don't mind the PG assuming main.cpp, ofApp.h, ofApp.cpp when generating a new project from scratch. But when importing, I think it would be better if it didn't assume anything and only scanned the src folder. It's particularly problematic for other people actually. I can easily remove the missing files from the project. But someone less IDE savvy who downloads an addon, uses the PG to generate a project and then encounters a weird compile error might not know what to do.