The "local addons" support looks like it's working well, thank you again for adding that! It looks like for VS at least I'm getting odd folders in the project ("filters" technically). It compiles fine anyway, and dragging the libs folder to local_addons/ofxAddon/libs so it "looks right" also works. I can test this on OSX as well if that's helpful, let me know!

there are five different different behaviors, depending on seven or so ways you can interact with the addons selector.

first, click on the addons field, type "ofxCv". then either:

1. hit "enter" or type a comma. "ofxCcv", a different addon, is selected. not sure why. or...
2. hit "space" or type a semicolon. the addon is not added, and if you type anything else it says "no results found". i would expect these to act more like typing a comma.
3. click anywhere else in the window. "ofxCv" exists as text but will not be included as an addon.
4. hit "tab". same as above, except you are now in the "platforms" field. even with "advanced" mode unchecked it's possible to delete the default platform, add non-existent platforms (and you can't un-delete it).
5. click on the addon name from the dropdown. the addon gets added, but the text also remains in addons field.

it looks like there are two desired behaviors: add an addon from the list, and leave the text you typed in the field until you select an existing addon. but they're getting a bit mixed up. the "platforms" menu seems a little more consistent in how it handles these.

add pgSimple and pgDev to this repo

ouch!

have a path like "/Users/zachlieberman/Downloads/of_v20150910_osx_release 2/apps/myApps"

see results like

"there's no src folder in this project path to update, maybe use create instead? (or use force to force updating)

in 0 seconds"

since the command line read "/Users/zachlieberman/Downloads/of_v20150910_osx_release" as the path

need to add quotes around path variables.

try to remove unnecessary errors and warnings in the project generator to make it easier to read

I would like to be able to open a successfully generated project in xcode or any other ide via the projectGenerator.
There could be an open button next to the log window's close button.
Maybe the following commands are useful:

osx: `òpen $DESTINATION_PATH``

linux: xdg-open $DESTINATION_PATH

I noticed this when using the pgElectron and dug in a little bit. I rebuilt the commandLine pg in both debug & release just now. Both are fine to create a project without addons, but I get a crash when using release mode to add addons to a project. I tried with a few different ones (ofxGui, ofxNetwork, some with only src folders and some with both src & libs folders) and didn't notice a pattern. Here's my output...

C:\Users\mattfelsen\Documents\Code\openFrameworks\github\apps\projectGenerator\commandLine\bin>commandLine.exe /verbose /ofPath=C:\Users\mattfelsen\Documents\Code\openFrameworks\github C:\Users\mattfelsen\Documents\Code\openFrameworks\github\apps\CMA2\Kinect2MeshSender /addons="ofxGui"

-----------------------------------------------
setting OF path to: C:\Users\mattfelsen\Documents\Code\openFrameworks\github
from -o option

target platform is: vs
project path is: C:\Users\mattfelsen\Documents\Code\openFrameworks\github\apps\CMA2\Kinect2MeshSender

using additional template

setting up new project C:\Users\mattfelsen\Documents\Code\openFrameworks\github\apps\CMA2\Kinect2MeshSender

←[0mloaded filter
←[0mreturning path ../../../

←[0mreturning path ../../../

←[0min fromFS, trying src C:\Users\mattfelsen\Documents\Code\openFrameworks\github\addons\ofxGui/src
←[0m    ofxBaseGui.cpp
←[0m    ofxBaseGui.h
←[0m    ofxButton.cpp
←[0m    ofxButton.h
←[0m    ofxGui.h
←[0m    ofxGuiGroup.cpp
←[0m    ofxGuiGroup.h
←[0m    ofxLabel.cpp
←[0m    ofxLabel.h
←[0m    ofxPanel.cpp
←[0m    ofxPanel.h
←[0m    ofxSlider.cpp
←[0m    ofxSlider.h
←[0m    ofxSliderGroup.cpp
←[0m    ofxSliderGroup.h
←[0m    ofxToggle.cpp
←[0m    ofxToggle.h
←[0mlisted 17 files in "C:\Users\mattfelsen\Documents\Code\openFrameworks\github\addons\ofxGui/src\"
←[0m    ofxBaseGui.cpp
←[0m    ofxBaseGui.h
←[0m    ofxButton.cpp
←[0m    ofxButton.h
←[0m    ofxGui.h
←[0m    ofxGuiGroup.cpp
←[0m    ofxGuiGroup.h
←[0m    ofxLabel.cpp
←[0m    ofxLabel.h
←[0m    ofxPanel.cpp
←[0m    ofxPanel.h
←[0m    ofxSlider.cpp
←[0m    ofxSlider.h
←[0m    ofxSliderGroup.cpp
←[0m    ofxSliderGroup.h
←[0m    ofxToggle.cpp
←[0m    ofxToggle.h
←[0mlisted 17 files in "C:\Users\mattfelsen\Documents\Code\openFrameworks\github\addons\ofxGui/src\"
←[0madding addon include path: ../../../addons\ofxGui/src
←[0madding addon srcFiles: ../../../addons\ofxGui/src\ofxBaseGui.cpp

After the last line gets printed I get the "commandLine.exe has stopped working" Windows dialog

it's really useful to see the command line string that we are using in the console output so we can go test it by hand if need be, ie the "projectGenerator -o="....." -r ......" string. I think that used to be in there at some point.

Thus, when an addon only lists it's primary addon (e.g. ofxHTTP), the dependent addons listed in the addons_config.mk file are not tracked down. Ultimately this will probably have to happen recursively making sure that the whole tree is traversed.

The makefile system respects the ADDON_DEPENDENCIES var and adds the required addons, so this fix will bring those two systems in line with one another.

I'm happy to take a look and implement this, but as there is active PG development at the moment, I don't want to interrupt until things calm just a bit.

The current styling of the code doesn't work well with the Xcode default styling.

Also, these two lines should be swapped to have the same order as in the implementation file.

void dragEvent(ofDragInfo dragInfo);
void gotMessage(ofMessage msg);

(copied from openframeworks/openFrameworks#4362 )

if i use the pgElectron to make a new project with ofxEdsdk (the develop branch, which has the proper libs/ofxEdsdk/lib path) then i get an EDSDK.framework added to the copy files phase with this path:

/Users/kyle/Documents/openFrameworks/le/Documents/openFrameworks/addons/ofxEdsdk/libs/EDSDK/lib/EDSDK.framework

which seems to be munging a relative path and an absolute path, with the "le" in the middle probably referring to "kyle/Documents".

other addons seem to work ok though.

there's some stuff in ofAddon (it's in the main repo, but I'm putting the issue here so it's easier to track) that seems kind of wrong to me. Paths are coming in either unix-y or windows-y, but it feels like we should make the decision to convert all paths to unix internally and only convert back when and if we need to at the project level (ie, visualStudioProject should make sure it outputs windows paths)

I'm talking specifically about stuff like this:

https://github.com/openframeworks/openFrameworks/blob/master/addons/ofxProjectGenerator/src/addons/ofAddon.cpp#L428-L432

which is making some assumptions and trying to be a bit smart about paths.... My intuition is that things like generating an OSX project on windows could break in weird ways here....

the tl;dr is - let's make sure to just use unix under the hood and convert to windows only when absolutely necessary.

When I click on the button next to where you type the project name, the following error pops up. It seems as though the document sketchAdjectives.txt is missing.

I'm getting a strange runtime error with both github and the nightly:

$ /Users/robert/Downloads/of_v20151008_ios_release/projectGenerator-ios/projectGenerator.app/Contents/Resources/app/app/projectGenerator -r  -o"/Users/robert/3rdParty/openFrameworks" -p"ios" /Users/robert/3rdParty/openFrameworks/examples/ios
Abort trap: 6

XCode 7.0.1, OS X 10.11

When debugging the commandLine project the error happens in the POCO_MAIN_APP(commandLineProjectGenerator) macro.

The stack trace is stopped on 0x1000d3c68 in Poco::Util::Application::init()

    0x1000d3c60 <+608>:  movq   %r14, %rdi
    0x1000d3c63 <+611>:  callq  0x1000d4060               ; Poco::Util::Application::processOptions()
    0x1000d3c68 <+616>:  leaq   -0x98(%rbp), %rdi
    0x1000d3c6f <+623>:  callq  0x100144ff0               ; Poco::Path::~Path()
    0x1000d3c74 <+628>:  addq   $0x258, %rsp

Any help with this would be great, I am unable to generate iOS projects, but OS X projects generate just fine.

I Just pulled current master of openframeworks and projectGenerator and compiled projectGeneratorLegacy successfully. Everytime I try selecting an addon, the addon above, or two steps above gets checked, depending on the position.
ProjectGeneratorSimple and guiFromParameters work as expected.
I am on Ubuntu 15.04.

because we use OF, the command line tool has a ton of dylib and dependancies baked in. It would be good to simplify things. for the most part, OF is used for text manipulation and file manipulation, so this can be written in poco / straight c++.

if we remove OF, can we make this a simple executable on OSX ?

also, we can likely remove pugixml if we want to for poco's simple xpath support, which covers about 95% of what we need.

I've updated the vs project files for the command line tool -- when I compile it I get these link errors:

Error   LNK2001 unresolved external symbol "public: static class std::vector<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class std::allocator<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > > > const LibraryBinary::archs" (?archs@LibraryBinary@@2V?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@B)    commandLine 



C:\Users\zach\Desktop\openFrameworks\apps\projectGenerator\commandLine\Utils.obj    1
Error   LNK2001 unresolved external symbol "public: static class std::vector<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class std::allocator<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > > > const LibraryBinary::targets" (?targets@LibraryBinary@@2V?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@B)    commandLine C:\Users\zach\Desktop\openFrameworks\apps\projectGenerator\commandLine\Utils.obj    1

if you select a project file to update, and add an addon to the project, it is not added to the project file or the addons.make file.

A common error for iOS Projects when using the project generator is to select the ofxiOS addon and related addons, such as ofxAccelerometer and ofxMultiTouch.

These addons are already included by default and it causes strange semantic errors by having multi of the same in each project.

Hiding these from being selected / seen will be a easy fix

I'm getting compile errors, looks like it's somewhere in @arturoc's commits from today (or I guess "yesterday" on Berlin time 😄) If I revert to the last commit from @ofZach's commandLineOptions branch merge I can compile.

Maybe related to the newly-regererated project files?

syntax error: identifier 'rsize_t' (compiling source file src\main.cpp) commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\corecrt_search.h   26
syntax error: identifier 'rsize_t' (compiling source file src\main.cpp) commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\corecrt_search.h   34
syntax error: missing ';' before '__cdecl' (compiling source file src\main.cpp) commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\corecrt_wstdlib.h  48
missing type specifier - int assumed. Note: C++ does not support default-int (compiling source file src\main.cpp)   commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\corecrt_wstdlib.h  48
missing type specifier - int assumed. Note: C++ does not support default-int (compiling source file src\main.cpp)   commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\corecrt_wstdlib.h  53
syntax error: missing ';' before '__cdecl' (compiling source file src\main.cpp) commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\corecrt_wstdlib.h  55
unrecognizable template declaration/definition (compiling source file src\main.cpp) commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\corecrt_wstdlib.h  60
'errno_t': 'inline' not permitted on data declarations (compiling source file src\main.cpp) commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\corecrt_wstdlib.h  60
missing type specifier - int assumed. Note: C++ does not support default-int (compiling source file src\main.cpp)   commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\corecrt_wstdlib.h  60
linkage specification contradicts earlier specification for 'errno_t' (compiling source file src\main.cpp)  commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\corecrt_wstdlib.h  60
'_Size': undeclared identifier (compiling source file src\main.cpp) commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\corecrt_wstdlib.h  60
unrecognizable template declaration/definition (compiling source file src\main.cpp) commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\corecrt_wstdlib.h  71
syntax error: missing ';' before '__cdecl' (compiling source file src\main.cpp) commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\corecrt_wstdlib.h  71
syntax error: missing ';' before '__cdecl' (compiling source file src\main.cpp) commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\corecrt_wstdlib.h  78
linkage specification must be at global scope (compiling source file src\main.cpp)  commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\corecrt_wstdlib.h  83
unrecognizable template declaration/definition (compiling source file src\main.cpp) commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\corecrt_wstdlib.h  83
'errno_t': 'inline' not permitted on data declarations (compiling source file src\main.cpp) commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\corecrt_wstdlib.h  83
missing type specifier - int assumed. Note: C++ does not support default-int (compiling source file src\main.cpp)   commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\corecrt_wstdlib.h  83
'errno_t': redefinition; multiple initialization (compiling source file src\main.cpp)   commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\corecrt_wstdlib.h  83
'_Size': undeclared identifier (compiling source file src\main.cpp) commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\corecrt_wstdlib.h  83
unable to recover from previous error(s); stopping compilation (compiling source file src\main.cpp) commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\corecrt_wstdlib.h  83
syntax error: identifier '_locale_t' (compiling source file src\main.cpp)   commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\math.h 481
syntax error: missing ';' before '__cdecl' (compiling source file src\main.cpp) commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\stddef.h   32
missing type specifier - int assumed. Note: C++ does not support default-int (compiling source file src\main.cpp)   commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\stddef.h   32
syntax error: missing ';' before '__cdecl' (compiling source file src\main.cpp) commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\stddef.h   33
missing type specifier - int assumed. Note: C++ does not support default-int (compiling source file src\main.cpp)   commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\stddef.h   33
syntax error: missing ';' before '__cdecl' (compiling source file src\main.cpp) commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\stddef.h   48
missing type specifier - int assumed. Note: C++ does not support default-int (compiling source file src\main.cpp)   commandLine C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\stddef.h   48
Error   D8040   error creating or communicating with child process  commandLine C:\Users\mattfelsen\Code\openFrameworks\github\apps\projectGenerator\commandLine\cl 1

Just making an app on OSX with only ofxNetwork added:

Command failed: /bin/sh -c /Users/adam/workspace/openFrameworks/projectGenerator-darwin-x64/projectGenerator.app/Contents/Resources/app/app/projectGenerator -o"/Users/adam/workspace/openFrameworks" -a"ofxNetwork" -x"osx" /Users/adam/workspace/openFrameworks/apps/myApps/myMildSketch
[ error ] ofDirectory: copyTo(): source directory does not exist
[ error ] ofFile: copyTo(): source file does not exist
[ error ] ofFile: copyTo(): source file does not exist
[ error ] ofFile: copyTo(): source file does not exist
[ error ] ofFile: copyTo(): source file does not exist
[ error ] ofFile: copyTo(): source file does not exist
[ error ] ofFile: copyTo(): source file does not exist
[ error ] ofFile: copyTo(): source file does not exist
[ error ] ofDirectory: listDir:() source directory does not exist: ""/Users/adam/workspace/openFrameworks/addons/ofxNetwork/libs/""

EDIT: Just realized I'm using an out-of-date PG, from Aug 30. This is fixed already.

openframeworks/openFrameworks#4290

Just for projects that require ofxOpenCv in their addons.make

So currently:

• opencvFaceExample
• opencvExample

(copied from openframeworks/openFrameworks#4361 )

i sometimes use dashes in my project names and the pgElectron interface seems to replace them with underscores when i try to update the project file, which means it fails to open the addons.make correctly, and also generates new source files.

maybe a better behavior would be to throw an error when trying to import something rather than automatically replacing it with underscores?

I'm trying to set up a project with this sort of structure (it's a slight deviation from this setup)

PROJECT_ROOT

• Apps
• Docs
• submodules
  • openFrameworks (i.e. OF_ROOT)
  • ofxAddon1
  • ofxAddon2

This is nice because it lets us manage both OF and all the addons as git submodules. What I'm seeing with the commandLine tool is it takes arguments from the addons="" param and tries to append it to $OF_ROOT\addons, which doesn't make sense in this case, even if I pass a full path as the addon param. My verbose output is below.

I'm much newer to VS than Xcode...adding addons to existing projects in Xcode is pretty easy with the plugin, but I'm finding it a pain to add addons to VS that require manual setup of include paths, library paths, library names, etc. so I was hoping the commandLine tool would be able to help with updating existing projects. Does this seem like the right approach?

> commandLine.exe /verbose /ofPath=C:\Users\mattfelsen\Documents\Code\Projects\CMA2\submodules\openFrameworks C:\Users\mattfelsen\Documents\Code\Projects\CMA2\Sketches\TestAddon /addons=C:\Users\mattfelsen\Documents\Code\Projects\CMA2\submodules\ofxEyeTribe


[notice ] PG_OF_PATH not set (see help), -o parameter needs to be set (-h for options)
[notice ] C:\Users\mattfelsen\Documents\Code\Projects\CMA2\Sketches\TestAddon does not exist, using 'create' mode
[notice ] setting OF path to: C:\Users\mattfelsen\Documents\Code\Projects\CMA2\submodules\openFrameworks


[notice ] -----------------------------------------------
[notice ] setting up a new project
[notice ] target platform is: vs
[notice ] project path is: C:\Users\mattfelsen\Documents\Code\Projects\CMA2\Sketches\TestAddon
[verbose] loaded filter
[verbose] returning path ../../submodules/openFrameworks/

[notice ] parsing addon: C:\Users\mattfelsen\Documents\Code\Projects\CMA2\submodules\openFrameworks\addons
[verbose] in fromFS, trying src C:\Users\mattfelsen\Documents\Code\Projects\CMA2\submodules\openFrameworks\addons\C:\Users\mattfelsen\Documents\Code\Projects\CMA2\submodules\ofxEyeTribe/src
[ error ] ofDirectory: listDir:() source directory does not exist: ""C:\Users\mattfelsen\Documents\Code\Projects\CMA2\submodules\openFrameworks\addons\C:\Users\mattfelsen\Documents\Code\Projects\CMA2\submodules\ofxEyeTribe/src\""
[verbose] trying get folders recursively C:\Users\mattfelsen\Documents\Code\Projects\CMA2\submodules\openFrameworks\addons\C:\Users\mattfelsen\Documents\Code\Projects\CMA2\submodules\ofxEyeTribe/libs
[ error ] ofDirectory: listDir:() source directory does not exist: ""C:\Users\mattfelsen\Documents\Code\Projects\CMA2\submodules\openFrameworks\addons\C:\Users\mattfelsen\Documents\Code\Projects\CMA2\submodules\ofxEyeTribe/libs\""
[ error ] ofDirectory: listDir:() source directory does not exist: ""C:\Users\mattfelsen\Documents\Code\Projects\CMA2\submodules\openFrameworks\addons\C:\Users\mattfelsen\Documents\Code\Projects\CMA2\submodules\ofxEyeTribe/src\""
[verbose] adding addon include path: ../../../addons\C:\Users\mattfelsen\Documents\Code\Projects\CMA2\submodules\ofxEyeTribe/libs
[verbose] adding addon include path: ../../../addons\C:\Users\mattfelsen\Documents\Code\Projects\CMA2\submodules\ofxEyeTribe/src
[notice ] saving addons.make
[notice ] project created!
[notice ] -----------------------------------------------


1 project created in 0.325195 seconds

this is kind of weird:

projectGenerator -o . -c -p apps/myprojects/example

the project to create or update always needs to be specified so always adding -p seems redundant.

this:

projectGenerator -o . -c apps/myprojects/example

would be better.

Also having to always specify -c or -u seems redundant too. By default it should create if the project doesn't exists yet or update if it's already there like:

projectGenerator -o . apps/myprojects/example

that way if we have an env var to specify where OF is located (which should be explained in the usage maessage) we can do:

projectGenerator apps/myprojects/example

to create a project with the default settings otherwise the usage is too complicated.

also in the message, usage, usually specifies the format in which it has to be called, ie:

usage: commandline [options] path

or if the command is mandatory:

usage commandline [options] command path

wonder if we did this instead of embedding the tool into node project:

then, we could include some info about how to use the command line tool in the folder and folks could set it up how they want.

I know this doesn't matter for linux, but for windows / osx it could lead to more visibility for the command line tool.

i'd like to propose two changes:

1. every time the user clicks "generate" or "update" we open the folder. this acts as confirmation that it worked. only pop up the modal if there is an error.
2. next to "generate" or "update" we have "generate and launch" or "update and launch" which opens the project file itself.

i think the way it's designed now is very useful for PG development/debugging, but the more i use it the more it feels unnecessary to open the modal every time. i really just want to open the project file after i've updated it.

in osx, from OF rooot:

apps/projectGenerator/commandLine/bin/projectGenerator -o /Users/arturo/Desktop/openFrameworks/ examples/addons/allAddonsExample

tries to create the project in:

project path is: /Users/arturo/Desktop/openFrameworks/apps/projectGenerator/commandLine/bin/examples/addons/allAddonsExample

and:

apps/projectGenerator/commandLine/bin/projectGenerator -o . examples/addons/allAddonsExample

fails to parse . as a directory
apps/projectGenerator/commandLine/bin/projectGenerator -o /Users/arturo/Desktop/openFrameworks/ examples/addons/allAddonsExample

I just downloaded the nightly build of_v20151030_linux64_release and it seems that the command line app binary is missing. Probably just a linux bug.

this is the source of the issue that @NickHardeman was seeing on 10.8:

electron/packager#111

I'm not 100% sure how to handle updating dependencies' dependencies but it looks like there's a fix for this issue there...

pgSimple compiles and starts (I didn't test any actual functionality) without issue, but I get linking errors related to LibraryBinary for pgLegacy. I think whatever happened this commit 3e412ab needs to happen as well? That looks like a non-trivial reorganization so I don't want to muck things up...

The reason I'm bothering with pgLegacy rather than using the commandLine tool is that I can't add addons that are outside of OF_ROOT\addons, which I reported here #23

need to investigate how to pass in paths with spaces in them and have them not get broken up into multiple tokens (right now the PG gui fails with path spaces since the tokens get broken up). Might be as simple as just using quotes.

I just opened an old project where one of its depending addons is missing. In my case the projectGenerator complains that ofxCv is missing, I should download, put the addon in the addons folder and finally rescan it. The provided rescan link does not work, so I had to reopen the projectGenerator.

I created a project with the new project generator, and added ofxOsc. It added the win32 folder to the project, which causes Xcode to complain winsock2.h not found.

I tried running make from the commandLine folder but ran into a bunch of Poco errors. Here's some of them.

obj/linux64/Release/src/main.o: In function 'main': main.cpp:(.text.startup+0x106b): undefined reference to 'Poco::Path::current[abi:cxx11]()' main.cpp:(.text.startup+0x112c): undefined reference to 'Poco::Path::current[abi:cxx11]()' main.cpp:(.text.startup+0x1141): undefined reference to 'Poco::Path::Path(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' main.cpp:(.text.startup+0x116d): undefined reference to 'Poco::Path::Path(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' main.cpp:(.text.startup+0x1192): undefined reference to 'Poco::Path::toString[abi:cxx11]() const' main.cpp:(.text.startup+0x11dd): undefined reference to 'Poco::Path::Path(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' main.cpp:(.text.startup+0x1212): undefined reference to 'Poco::Path::toString[abi:cxx11]() const' main.cpp:(.text.startup+0x2d92): undefined reference to 'Poco::Path::Path(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' main.cpp:(.text.startup+0x2dbc): undefined reference to 'Poco::Path::toString[abi:cxx11]() const' /home/kojo/dev/ofxPG/commandLine/obj/linux64/Release/addons/ofxProjectGenerator/src/addons/ofAddon.o: In function 'ofAddon::exclude(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >)': ofAddon.cpp:(.text+0x93c): undefined reference to 'Poco::RegularExpression::RegularExpression(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int, bool)' ofAddon.cpp:(.text+0xb34): undefined reference to 'Poco::RegularExpression::match(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long) const' ofAddon.cpp:(.text+0xc77): undefined reference to 'Poco::RegularExpression::match(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long) const' ofAddon.cpp:(.text+0xdaf): undefined reference to 'Poco::RegularExpression::match(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long) const' ofAddon.cpp:(.text+0xef4): undefined reference to 'Poco::RegularExpression::match(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long) const' ofAddon.cpp:(.text+0x121e): undefined reference to 'Poco::RegularExpression::match(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long) const' /home/kojo/dev/ofxPG/commandLine/obj/linux64/Release/addons/ofxProjectGenerator/src/addons/ofAddon.o:ofAddon.cpp:(.text+0x14a1): more undefined references to 'Poco::RegularExpression::match(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long) const' follow

It just keeps going. I've run into a similar problem trying to build an existing project. I keep getting Poco errors. OpenFrameworks builds fine by itself but I can't build an existing project or the PG.

still running after a working project for building shader tutorials (see openframeworks/openFrameworks#4194), I tried to build what looks like a command line tool project generator to my eyes, but it fails with :

/home/antoine/lib-src/openFrameworks/apps/projectGenerator/commandLine/src/main.cpp:14:28: fatal error: CBLinuxProject.h: Aucun fichier ou dossier de ce type
 #include "CBLinuxProject.h"

I'm running Ubuntu 64bit and try to build this one from OpenFrameworks submodule

any hint ?

Please exclude node_modules folder from project generator - electon, i suppose it's unnesesary files to download.

Hello :)

After some discussions with @ofZach and others about PG simplification, I'm making a plan of attack to merge both the PG Simple and the PG Legacy.

This issue can be seen as a continuation of openframeworks/openFrameworks#3941 where @ofTheo states that we have to be able to generate exemples and update projects in order to kill the PG Legacy. Another great feature is to be able to generate project files for any platform.
So this thread could be used to clarify & discuss directions and new features for a unified PG.

I saw @arturoc 's PG refactoring which (temporarily) puts all common code in a cross-platform ofxAddon. This is meant to be put somewhere else later.
The ProjectGenerator, the ProjectGenerator CommandLine and other users will then be able to use this common code. (ex: @bakercp plans to use this common code in his ofSketch app).

Zach notes that there's no need to use OF or that we need to simplify the UI (which he has already begun).

For the record, @kritzikratzi coded a command line tool to add, remove and update addons to an of project which can be useful too.

Btw, there's currently a PG submodule while having the PG core in the OF addons folder (ofxProjectGenerator)... having the PG code in 2 different repos makes no sense to me...

So here's what I suggest doing:

• Add pages to the PG:
  • Create page: not much to do. (copy of PG Simple)
  • Update Page (Adapt PGLegacy code)
    • Usage: Load project, Settings are imported/detected into UI and can then be altered / updated.
    • Add Generate Examples page (adapt code from PGLegacy)

Maybe all those pages can share a “target” bar where you can tick the desired targets.

And I'm wondering, what's the best way to achieve this? (regarding versioning)

• Create a new folder called something like "ProjectGenerator Unified" or
• Alter the PG Simple

The "Electron Framework" is duplicated 3x for some reason. We can replace two of these with symlinks like this:

cd projectGenerator.app/Contents/Frameworks/Electron\ Framework.framework
rm Electron\ Framework
rm -rf Versions/Current/
ln -s Versions/A Current/A
ln -s Versions/Current/Electron\ Framework Electron\ Framework

Here is the Project Generator before:

And after:

This makes the .zip for OS X go from 224MB to 172MB.

I'm seeing this everywhere now :

 ←[1m←[31m

ie:

 updating project C:\Users\zach\Desktop\openFrameworks\apps\myApps\myWarmSketch
 ←[1m←[31mofFile: remove(): 

when there is a warning or error. I believe this is related to:

https://github.com/openframeworks/projectGenerator/blob/master/commandLine/src/main.cpp#L41-L59

can we maybe disable this for OSX and windows? It's also going to cause issues with the gui since it captures the results of feedback and reports it back (and these color commands come out as text)

If an xcode project is generated outside the openFrameworks directory, xcode does not find openFrameworks headers and complains that ofMain.h is not found.
A project generated in /apps/ worked fine.
It works, if I compile the project using the makefiles.

osx 10.10,
pg: 592b4d3
oF: 9b884b68dd6001562fcb382fb3caa50054904ed7

Upon a fresh clone of OF and projectGenerator, I built the command line project generator and then tried to generate a project with it.

dyld: Library not loaded: @executable_path/libfmodex.dylib
  Referenced from: /src/openframeworks.openframeworks/apps/projectGenerator/commandLine/bin/./projectGenerator
  Reason: image not found
[1]    9384 trace trap  ./projectGenerator

What am I missing here? I see lots of Xcode solutions but none that really describe what needs to be done here.

I can't find this documented anywhere.

What are the Addon_config equivalents for the following Xcode commands:
LIBRARY_SEARCH_PATHS (Library Search Paths)
HEADER_SEARCH_PATHS (Header Search Paths)

Spec:

# dependencies with other addons, a list of them separated by spaces 
    # or use += in several lines
    # ADDON_DEPENDENCIES =

    # include search paths, this will be usually parsed from the file system
    # but if the addon or addon libraries need special search paths they can be
    # specified here separated by spaces or one per line using +=
    #ADDON_INCLUDES = 

    # any special flag that should be passed to the compiler when using this
    # addon
    # ADDON_CFLAGS =

    # any special flag that should be passed to the linker when using this
    # addon, also used for system libraries with -lname
    # ADDON_LDFLAGS =

    # linux only, any library that should be included in the project using
    # pkg-config
    # ADDON_PKG_CONFIG_LIBRARIES =

    # osx/iOS only, any framework that should be included in the project
    # ADDON_FRAMEWORKS =

    # source files, these will be usually parsed from the file system looking
    # in the src folders in libs and the root of the addon. if your addon needs
    # to include files in different places or a different set of files per platform
    # they can be specified here
    # ADDON_SOURCES =

    # some addons need resources to be copied to the bin/data folder of the project
    # specify here any files that need to be copied, you can use wildcards like * and ?
    # ADDON_DATA = 

    # when parsing the file system looking for libraries exclude this for all or
    # a specific platform
    # ADDON_LIBS_EXCLUDE =

         # binary libraries, these will be usually parsed from the file system but some 
    # libraries need to passed to the linker in a specific order 
    ADDON_LIBS =

I would like to be able to save a project config file, so i can modify it later and add new addons or libraries.
Also if I want to put a project on github, it would be enough to just include a cross plattform config and other users can generate their own IDE specific projects.
This could be a simple json file.

Are there any disadvantages of this approach?
I could give it a try in october.

Just for reference here is a forum post.
http://forum.openframeworks.cc/t/updating-projects-using-the-project-generator/19946

https://travis-ci.org/openframeworks/projectGenerator/jobs/76854881

seems some of the last commits are breaking the build. The actual code is in the core repository so it's hard to track where it was broken.

i'm getting this error:

Uncaught Exception:
Error: ENOENT: no such file or directory, open '/home/arturo/Downloads/of_v20150910_linux64_release/projectGenerator-linux64/resources/app/node_modules/moniker/dict/sketchAdjectives.txt'

The Electron app alerts me:

Error...
There was a problem generating your project... /Users/crucial/code/idmx/of_v20151008_osx_release/apps/myApps/PlaySPLOM

Command failed: /bin/sh -c /Users/crucial/code/idmx/of_v20151008_osx_release/projectGenerator-osx/projectGenerator.app/Contents/Resources/app/app/projectGenerator  -o"/Users/crucial/code/idmx/of_v20151008_osx_release" -a"ofxGui,ofxOsc" -p"osx" /Users/crucial/code/idmx/of_v20151008_osx_release/apps/myApps/PlaySPLOM

OS X crash reporter reports:

VM Regions Near 0:
--> 
    __TEXT                 00000001032a8000-000000010398b000 [ 7052K] r-x/rwx SM=COW  /Users/USER/*/projectGenerator.app/Contents/Resources/app/app/projectGenerator

Application Specific Information:
abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib          0x00007fff94576286 __pthread_kill + 10
1   libsystem_c.dylib               0x00007fff88eba9b3 abort + 129
2   projectGenerator                0x000000010337b15d Poco::SignalHandler::handleSignal(int) + 45
3   libsystem_platform.dylib        0x00007fff8e7d5f1a _sigtramp + 26
4   projectGenerator                0x0000000103533ec6 std::__1::__tree_node_base<void*>*& std::__1::__tree<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >::__find_equal<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >(std::__1::__tree_node_base<void*>*&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 38
5   projectGenerator                0x0000000103503890 std::__1::__tree<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >::__insert_unique(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 38
6   projectGenerator                0x000000010330cd59 Poco::Util::OptionProcessor::processCommon(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) + 393
7   projectGenerator                0x000000010330d0e0 Poco::Util::OptionProcessor::processUnix(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) + 480
8   projectGenerator                0x000000010330cbc0 Poco::Util::OptionProcessor::process(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) + 128
9   projectGenerator                0x0000000103304726 Poco::Util::Application::processOptions() + 358
10  projectGenerator                0x00000001033041c8 Poco::Util::Application::init() + 616
11  projectGenerator                0x00000001032a9c61 main + 49
12  projectGenerator                0x00000001032a9c24 start + 52

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x0000000000000006  rcx: 0x00007fff5c956ee8  rdx: 0x0000000000000000
  rdi: 0x0000000000000713  rsi: 0x0000000000000006  rbp: 0x00007fff5c956f10  rsp: 0x00007fff5c956ee8
   r8: 0x00007fff5c957408   r9: 0x00000000fffffff8  r10: 0x0000000008000000  r11: 0x0000000000000206
  r12: 0x0000000000000000  r13: 0x00007f9c0b008598  r14: 0x00007fff7a8cf300  r15: 0x00007fff5c957708
  rip: 0x00007fff94576286  rfl: 0x0000000000000206  cr2: 0x00007fff78dc9fd8

of_v20151008_osx_nightly fresh download

Possibly a duplicate of #51

add examples to the help screen & look at making friendlier error messages. Also, better explanation about how to use the command line switches.

i've had this problem only recently but i don't use the PG much except for creating empty projects so it might have been like this always.

when updating a project with exisiting source it should add only files with the allowed extensions:

• c
• cpp
• cc
• cxx
• h
• hpp
• hxx ?
• iml
• ipl
• m
• mm
• glsl ?
• vert ?
• frag ?

right now it's adding anything in the folder and some files like .orig from merges from github or backup files from some editors get into the project file which makes the compilation fail.

here's my thought about how to do local addons:

(a) allow user to specify them in the settings.json

(b) convert them internally in the GUI to an absolute path (it just gets confusing to have relative paths from OF and relative paths from the project. This absolute path is based on the path to OF so if OF moves, this doesn't break.

(c) show them in the drop down as well as the core addons

(d) pass them into the PG via their absolute path.

projectGenerator -o"/Users/zachlieberman/Documents/openframeworks/git/openFrameworks" -a"/Users/zachlieberman/Documents/openframeworks/git/openFrameworks/otherAddons/ofxDummy" -p"osx" "/Users/zachlieberman/Documents/openframeworks/git/openFrameworks/apps/myApps/myImposingSketch"

(e) they get converted to relative paths in the PG and added to the project

all this is generally working, but I haven't figured out what do about importing? (ie, read the addons.make, convert these to absolute paths, attempt to match them against the set local addons, etc). The gui "update" command kind of trashes the addons.make file so it's important to figure out what import should do.

cc @mattfelsen @arturoc