Would like a way to easily 'export' a whole project

[GoogleCodeExporter]

I like firebreath in concept but it will be very difficult to use it for what I 
need to do, because the project I create using fbgen.py gets strewn throughout 
the firebreath source tree. The plugin that I am building is going to be only a 
component of a larger, overarching project. And as a self respecting hacker I 
really cannot bring myself to check in a whole foreign source tree into my own 
just to be able to use firebreath. Is there a way to cleanly extract just the 
bits that are needed to build the plugin and keep stuff like the IDL up to date 
(I don't mind a cmake dependency) and separate it completely from other stuff 
like the prep* commands, fbgen.py, and other stuff that isn't needed for 
building an existing project?

I intend to manually go through the source tree and figure out what's needed 
and what's not, and rearrange the structure of the generated vcproj files, but 
that's a lot of work and it makes me wonder whether I should just create a raw 
NPAPI plugin and a raw ActiveX plugin.

Thanks, and keep it up!

Original issue reported on code.google.com by joshua.m...@gmail.com on 18 Aug 2010 at 1:54

• Merged into: #61

[GoogleCodeExporter]

The only thing in the source tree generated by fbgen -- and the only thing you 
need -- is your project directory in /projects/<project name>

So if you create a plugin called MyCoolPlugin, it will be placed in 
projects/MyCoolPlugin and that is the only directory that you need to save.

The other files you see are in build/ and those are generated each time you run 
the prep script, which runs cmake.  The vcproj files should never be modified 
directly; instead, you should use the cmake project files (CMakeLists.txt, 
PluginConfig.cmake, and projectDef.cmake).

We realize that this is a change for most developers -- particularly windows 
developers.  Please just trust us that we have really looked into every other 
way that we could find of doing it, and this was the way that was simplest for 
everyone and allowed the most flexibility.  If you take the time to learn to 
use the cmake project files properly, it is really not difficult at all to keep 
things going, and making things cross platform is hugely simplified.  If you 
don't care about cross platform -- well, sorry, we do, and we have to make the 
system support it. =]

Thanks for the feedback. I'll use this issue to create an entry on the FAQ.  If 
you have any other questions, you may post them here, but I recommend going to 
the dev list (which is also a users list).

Original comment by taxilian on 18 Aug 2010 at 3:50

• Changed state: Invalid

[GoogleCodeExporter]

After re-reading your comment, there is another step that we have discussed, 
but nobody has had time to implement, that would probably help you.  It should 
be relatively easy to add a feature to be able to specify the location of the 
projects/ dir so that it doesn't have to be in the firebreath source tree (and 
the build/ dir as well, for that matter).  All we need is for someone to decide 
how that should work and take the hour or two necessary to implement it.  I'm 
willing to help you with it if you would like this feature and are willing to 
do a little legwork.  Otherwise, I'll get to it, but it'll be a little while as 
I'm swamped on another project.

You can find me on irc, on the mailing list, via google talk @ 
taxilian@gmail.com, or any number of other ways.

Original comment by taxilian on 18 Aug 2010 at 3:59

[GoogleCodeExporter]

I think the knowledge that everything is autogenerated except for what's in the 
project/ directory is good enough for me. However you do still need some 
directories that are present in the source tree, such as the top level cmake/ 
directory as well as parts of the src/ directory. Could that theoretically be 
installed in a /usr or Program Files directory as a 'library' of sorts, and be 
able to easily reconfigure the project to look in that directory for all the 
cmake / extra source files that are needed? Or is there already a set of 
environment variables that can control that? If so, that would be immensely 
useful to me.

Thanks for the quick response.

Original comment by joshua.m...@gmail.com on 18 Aug 2010 at 5:53

[GoogleCodeExporter]

you need pretty much everything in the firebreath/ source tree to build, 
however you can just get that from firebreath's source control on each machine. 
 That would be the advantage to adding the feature so that you can specify the 
location of the projects/ and build/ directories is that it would make it 
possible to have the firebreath source tree seperate from the projects/ 
directory where your code lives.

Firebreath is a framework, not a library; you can't just include it, it's more 
the other way around.  You build firebreath and tell it where your project is 
to include that.

Original comment by taxilian on 18 Aug 2010 at 1:39

[GoogleCodeExporter]

Right, well my company has this policy of having a 'toolchain' repository that 
everyone must have checked out on their system. This toolchain could definitely 
include the firebreath source. Let me try and make the scenario I'd like to 
make possible very clear:

1. I generate a project with fbgen.py, output result is in projects/MyPlugin
2. I move MyPlugin to my source control under e.g. C:/src/myproj/MyPlugin
3. Firebreath is checked in to a DIFFERENT area, e.g. 
C:/toolchain/noarch/firebreath-1.1.1
4. Somehow, I would like to be able to successfully generate the project for 
MyPlugin while referencing firebreath in the toolchain directory, something 
like:

C:/toolchain/noarch/firebreath-1.1.1/prep2008.cmd -in C:/src/myproj/MyPlugin 
-out C:/src/myproj/build/MyPlugin

...then I can build it:

vcbuild C:/src/myproj/build/MyPlugin/MyPlugin.sln 'MinSizeRel|Win32'

Is *this* manner of separation possible and is that the feature you are 
suggesting I could help with? It kind of sounds like it, but I'd like to make 
sure.

Thanks for your helpful responses so far!

Original comment by joshua.m...@gmail.com on 18 Aug 2010 at 3:23

[GoogleCodeExporter]

This is exactly the type of seperation that would be possible as soon as 
someone takes the time to implement it.  We've discussed the need several times 
on the list, but nobody has had time to do it yet.

Original comment by taxilian on 18 Aug 2010 at 3:45

[GoogleCodeExporter]

Okay, then can we reopen this issue to track the development of that feature?

I may be able to help, but not for another month or two.

Original comment by joshua.m...@gmail.com on 18 Aug 2010 at 9:31

[GoogleCodeExporter]

I have created a new issue for this and marked this as duplicate for that issue.

Original comment by taxilian on 18 Aug 2010 at 9:40

• Changed state: Duplicate