Stuff moving around


#1

Jules, when are you finished with moving stuff around ? Its getting kind of tedious to edit my CMakeLists.txt files for each git pull :wink:

Edit: Or I should just make sure everyone in the project does a git pull to a specific revision… but I don’t know how in git. Yet…


#2

I can’t promise to ever stop moving things around! I’m not going to hold back from shuffling internal files around, because I don’t expect people to reference them directly from their own projects… If you’re using the amalgamated files or templates, or even if you’re building the static library and linking to it, nothing I’ve moved should make any difference to you at all. So you must be using cmake to directly build all the juce source files… which is seriously off-piste! Why are you doing it that way?


#3

Mainly because its a serious PITA debugging using the amalgamated stuff…

Edit: Plus everything else (20 or so applications + libraries) are using CMake…


#4

Just include the amalgamted template then - that what I do, and I bet I do more debugging inside the library code that you do!


#5

Hmm… no doubt. I’ll try it out.


#6

You’ve broken my dream. I’d have sweared you always write code right the first time, and never ever need a debugger at all! :wink:


#7

If you’ve figured out how to do that please by all means…share the secret


#8

Ooh, on a related note…

I’ve dug out and dusted off my old ZipOutputStream code (for easily creating zip archives), and would like to share it. However, it needs to include the zlib headers. In the olden days, people would be traditionally setting up their IDEs to point to the Juce folder via their include folders, so it was easy to just have an #include “src/io/streams/zlib/zlib.h” (or whatever) to use the one that comes with Juce. Now things are different, what would you say the best way to handle such a thing is (so that i can easily share the code without people having to tinker with anything)? This is the list of options I’ve come up with…

  1. just have a copy of the zlib headers with the code, and specify that the user let juce link its own zlib
  2. modify the jucer project export to also set project-specific include folders to point to the juce folder, and use the old approach
  3. put the entire zlib in with it, and specify that the user NOT use juce’s zlib
  4. make Juce provide additional headers for including zlib (e.g. Juce_zlibHeader.h); though im not sure how that would work with the amalgamated approach

It’s a bit fiddly anyway- I have to make sure i wrap the include with the same namespace as Juce uses for it to link properly. Not a problem once aware of it, but provided a moment of head scratching :slight_smile:

[incidentally, it looks like that zlib option isn’t present in the jucer’s flags page- although I may be using a slightly older version]

Any suggestions? I just want to make it clean so its easy for people to pick up and use, as it’s very handy (plus I keep getting requests for it as my old hosted space died long ago :))

[edit: of course the neatest solution would be for it to be tidied up proper-like and stuffed into juce itself ;)]


#9

There’s no real perfect answer.

I have both zlib and bzip in my project. Oh well.


#10

Weird coincidence - I just needed a zip file builder today so started writing one. While I was writing it, you made this post… To start with I’m just adding a subclass to ZipFile to do it, and not doing any compression, but let me check that in and maybe you can add to it to do everything else you need…