Juce static library project doesn't match settings

This is excatly what I was afraid of, that IntroJucer would be mandatory to perform a build!

How on earth is it more comfortable to “include the source directly” ?? Every time Jules moves, renames, adds, or deletes a source file it would be necessary to update your project. Or did you mean, only adding the module source files (e.g. “juce_core.cpp”)? Because if you only add the modules then source tree browsing and breakpoint setting because quite burdensome. We talked about this way back when the module system was being designed and the consensus was that we always needed to have some project with the full source tree available, for browsing.

It is a bad state of affairs that important functionality is being lost just to accommodate a new build tool!

1 Like

I personally still use the static library for just about everything.

Matt

sorry vinn, i can’t get your point. that jules changes the stl iretator debug behavior? That the static library project has different settings? That has nothing todo with the introjucer or the modulized juce. This are disadvantages/linkage problems you can always have when you are using static libraries.

Which functionality is lost? There is still a static library project, but it has limitations, but these are limitations of static libraries!

I cannot see whats your problem with the introjucer is, It has never been so easy to manage your builds for 3 complete different platforms (mac/win/android) with one click.
( i know you will disagree :wink:

Manually adding Juce sources to your existing project means either losing the ability to debug, or losing the ability to pick up changes to the static library project (i.e. when sources are added, removed, or renamed).

sorry i don’t understand, because i going the full introjucer way (including the full source tree) i can do all the funny things like debug etc…

but you are using the static library, so what is the main fundamental design change between the old juce static library, and the new juce static library?

Oh…

Well, nothing. Its just that in the past, I maintained my own project file. So I checked the GIT log and manually updated it for files getting added, removed, and renamed. It was something of a hassle.

So, in my original post I asked the question how can I pick up Jules changes to the project, while maintaining my own custom settings changes?

To be clear, it is not sufficient for me to have just the module sources (e.g. juce_core.cpp). I need to have the full juce source tree available for browsing (juce_Component.cpp, et. al.) and setting breakpoints. I can’t imagine how anyone can work without this - Jules included.

Nobody works without it… I debug all day long, quite happily. I don’t really understand why you think there’d be any problem doing so!

Personally I think the Introjucer is a fantastic tool. For creating small test apps, there really is no quicker way to get up and running. This must also be incredibly easy for people new to Juce to get up and running, no building libraries, no fuss linking or dealing with include/library paths, it all just works.

I also like the way you can include a local copy of the relevant modules. Building is much quicker than before and you can be sure that the version of Juce you are using with that project works. I tend to keep large projects with their own, stable copies of the modules and have small, quick and dirty test apps use a shared tip copy of Juce. Then I can just update the large project’s module folder periodically as new features emerge or bugs have been fixed.

If you really don’t want to use the Introjucer can’t you just include the sources yourself and provide an appropriate AppConfig file? Most other libraries I’ve used have some config file as a bare minimum, usually with some dependancy on make to generate them. You can always do anything that the Introjucer does manually if you really need to.

I think anything that can make Juce easier and quicker to use for the vast majority of people has to be a step in the right direction.

Well, check this out:

So, this ambiguous statement can be interpreted two ways. These images should make it clear:

(1) Case ONE: Juce modules only, added directly to project:
[attachment=1]JuceCode1.png[/attachment]

(2) Case TWO: Juce modules plus original sources, added directly to project:
[attachment=0]JuceCode2.png[/attachment]

So, its pretty clear that for case one, locating a file to set a breakpoint is going to be a pain in the ass. You would need to either use the Windows Explorer to locate the source file in question, or navigate your way to it using File->Open… and then picking through the Open common dialog. Furthermore, find in files would no longer work.

For case two, things are much easier for debugging. There is no problem whatsoever, just open the appropriate file and set your breakpoint. Additionally, it is easier to open up a header to inspect an interface if you want to look at a particular class to find out what’s available.

However, for case two, we have a new problem: when time a file is added, removed, renamed, or moved in the latest tip, EVERY project which has the Juce sources added to it needs to be updated manually! Holy smokes, that sucks!

At this point, the trend is to cry “USE INTROJUCER” which “automates the inclusion of Juce sources” blah blah blah. But this is not an option for me, and many other people. For this reason, we have three alternatives:

  1. Use the amalgamated form of Juce. For this to be effective, Jules needs to keep the amalgamation up to date, or else it will always be a little bit behind in terms of compile errors and functionality. Whoever maintains the amalgamation will always be trying to play “catch up” to changes in the tip. For this reason, I feel official support for the amalgamation should be maintained instead of dropped.

  2. Use the static library juce project located in extras. It would be ideal if we could keep official support for these projects instead of dropping them, for the same reasons as keeping support for the amalgamation. Because Jules is always the “first to know” about changes in the source tree, it is logical for him to migrate those changes to the static library. If Jules keeps a test application that links against the static library project, resolution of problems with that project will be swift. Besides, if IntroJucer has so many fancy code maintenance features, shouldn’t it be possible to automate the generation of the static library projects in extras using the IntroJucer itself?

  3. Use a custom static library project (which has to be manually maintained, but can be shared among multiple projects). This has been my personal solution to date. Although this requires additional effort, it is made much simpler if the static library projects are kept up to date (because one can start with that project and re-apply custom settings via property sheets).

When I speak of “lost functionality”, it is these three use-cases that I refer to. If we drop official support for the amalgamation and/or the static library project, it is true that they might continue to work for a little while - but eventually the Juce source code will diverge enough to permanently break those two features.

To summarize my position, I feel that moving to mandatory usage of IntroJucer is a mistake, and that the marginal amount of additional effort required to keep official support for the amalgamation and static library projects is worth the benefits.

Both true statements, but the problem comes when IntroJucer is REQUIRED to build!

It is worth mentioning, one of the things I used to LOVE about Juce, was that it required no external build tools or configuration. juce_PlatformDefs.h intelligently figured out the platform and build environment features automatically and did what it needed to do. This was a great system. Compare this with the crap you find on GNU/Linux systems with autotools and various other build tools. “.mk” files? For some projects you have to choose some header based on your operating system and put it in a magic place to get the thing to build. Its like the dark ages. I always admired Juce’s zero-configuration solution and sought to emulate it when structuring my own code.

Unfortunately, mandatory usage of IntroJucer moves Juce away from its original elegant implementation and in the direction of the mess found on GNU/Linux environments. I agree that IntroJucer is a great tool for getting a project up and running, but it was also said about autotools that was a “great tool for getting a project to compile on different platforms.”

Most software libraries and applications are complex systems rich with interdependencies. I feel that a source code library which is designed to be easy to use without requiring external build tools is superior to one that depends on a separate application in addition to the development environment in order to create and build projects.

Vote NO for mandatory IntroJucer dependency!

Fair enough, I can see that being annoying.

Hmm, personally I always use “Jump To Definition” in XCode, seems to work fine, maybe a VC specific issue if its not picking up the classes from the includes. Also if I need to find a class that I dont have a symbol handy for I can just use Spotlight, seems to work a lot better than that glowing orby thing Windows has.

I get the point though but apart from the handy project generation stuff I can’t see what the Introjucer does that you can’t do yourself. Even the old style Juce had a Config file with the flags in it, hasn’t this just changed name to AppConfig so it can be done on a per app basis? I can’t really see what the Introjucer could do to make it mandatory, slightly more effort perhaps.

All I know is that it has greatly improved my workflow. If I have to include 3rd party libraries I tend to wrap them in modules now anyway so they can be easily included across multiple projects. If they have to be built statically, I just inlcude the libs in the module, makes things very portable.

Agreed. I believe, it is specifically the project generation feature that is the problem. Apart from the amalgamation, IntroJucer should not be required to easily

  1. Create a new project that uses Juce

  2. Update an existing project to add, remove, move, or rename juce library sources (e.g. juce_Component.cpp)

vinn, you need a static library project where all juce specific files are in? Thats all?
And this project should not be generated by introjucer, because introjucer is bad like autotools, and you have bad experiences with autotools? :wink:

[quote=“chkn”]vinn, you need a static library project where all juce specific files are in? Thats all?
And this project should not be generated by introjucer, because introjucer is bad like autotools, and you have bad experiences with autotools? ;)[/quote]

Well, keeping official support for the static library build and making sure it works is what I’m pitching here.

I’ve taken pains to be clear that IntroJucer is not inherently “bad” - as many have pointed out, it serves a useful function. But I think it would be harmful if IntroJucer was required for someone to create or maintain a project that uses Juce.

I think it would be absolutely wonderful if IntroJucer could automatically generate the static library projects and Jules would keep those projects up to date when the source tree changes, instead of deprecating and then dropping support for these projects which is the current direction we’re headed in. If I have the option of simply picking up a new set of project files when the Juce source tree is updated and then re-applying my settings (perhaps this could be done on my end using a .patch file and set of property sheets and XCode .xcconfigs), that would be a workable solution.

What is NOT a workable solution is one day the static library projects in “extras” disappears, there is no easy way of maintaining my own project aside from running IntroJucer myself, and the only convenient way to change settings like which modules are included, or whether or not there is support for ASIO (for example) is to use the IntroJucer to build my Visual Studio and XCode project files for my application.

I found an interesting work-around. I have added the module sources (e.g. juce_core.cpp) to my application project, but keep the static library project in the solution (Visual Studio 2010). I can set breakpoints in individual source files even though I don’t link with the static library.

This solves the problem of changing statics on the static library project (I just change it in my application). This solution allows setting breakpoints, and picking up changes in the source tree without losing settings.

However, it still requires that the static library project be kept up to date.

I am not sure if this works on XCode.

Can you please tell me how to build JUCE Modules as a static library.? and link it to my dll project

I think you are aware, that this is a five years old thread and that matt’s last post was 2013…?

Yes I know that, it is five years old thread… But is it neccessary that matt itself has to answer here ? Anyone who knows the answer can help me out. I have already created a topic and posted my issues but nobody replied to that

…just thought, because matt is the only one in this thread who said he would do a static lib. seems to be a very uncommon thing, if even possible

Linking your new thread here, so people can get to the latest discussion:

Good luck