If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Need a story for mozilla-config



Other Applications
Venkman JS Debugger
9 years ago
7 years ago


(Reporter: Gijs, Unassigned)


(Blocks: 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




9 years ago
Venkman's makexpi.sh script requires mozilla/config to be "somewhere". We need to fix that story now we don't have CVS.

- I don't want people to be forced to clone all of comm-central to build, that'd be madness.

- Requiring cvs co mozilla/config also seems a bit... weird.

- Other ideas include rewriting the scripts so they don't need this stuff anymore, in which case we probably lose synchronicity with the jar.mn + makefile method of building.

Ideas appreciated.

Comment 1

9 years ago
pymake could open new possibilities there, at least in the long run, not sure about what can be done in the short term.

Comment 2

9 years ago
(In reply to comment #1)
> pymake could open new possibilities there, at least in the long run, not sure
> about what can be done in the short term.

I'm not sure how that would work, but yes, we need a short-term thing. Basically, I am inclined to reason thus:

1. We could write a separate script that harcodes the right thing to do independent of jar.mn and the other files we currently exploit to do the build. This is undesirable for reasons of duplication as well as having-superfluent-stuff-in-there-forever. It'll undoubtedly get out of sync with the makefile stuff.
2. We could duplicate the mozilla/config functionality we need. This is undesirable for reasons of having-superfluent-stuff-in-there-forever as well as functionality: it would be arrogant at best to assume we can do as well as the mozilla-config scripts without introducing new bugs by rewriting everything ourselves.
3. We could copy the mozilla/config functionality we need. This will give us superfluent-stuff-in-there-forever, and possibly code that gets out of sync.
4. We could auto-pull mozilla/config from CVS. This will possibly give us code that is out of sync with trunk. It'll require having CVS to build Venkman, which kind of really sucks, given we were trying to get away from it...
5. We could auto-pull comm/mozilla-central. This will pull way to much and will *really* suck. Until we get partial clones, but I'm not holding my breath for any of that.
6. We could ask IT a separate repo for mozilla/config, or use a user-repo, and clone that.
7. We could not do anything and assume the user will supply some kind of mozilla/config.

I'm inclined to go with 3, 4, or 6. Robert, Alex, Karsten, what do you think? Did I miss some possibility?

I'm not sure if we could convince IT to keep a mozilla/config repo separate, but we can see about that, I suppose...

Comment 3

9 years ago
(In reply to comment #2)
> I'm inclined to go with 3, 4, or 6. Robert, Alex, Karsten, what do you think?
> Did I miss some possibility?

I actually would favor anything that would go using the Mozilla build system as far as possible, esp. given that this can be done even without a compiler as I proved with at least inspector for my work on the build system talk at MAOW Berlin. Unfortunately, I won't have my head free for thinking about a good solution to do all that until after that MAOW this weekend as I haven't even done testruns of my talks or things like this yet. But the environment there might turn up some interesting strings of thoughts, maybe resulting in a good idea of how to do it.

What would be interesting is to know exactly what requirements you want to have for this solution, i.e. if it must be makexpi.sh or if it can go through the build system if it's requirements aren't too high - e.g. no compiler, only MozillaBuild required on Windows - or does it have to be even less than that? How much? Can/should we have an automatically/periodically updated repo that offers the core build system without any real platform or app code?

Comment 4

9 years ago
I don't think it's useful to write a tool to replace mozilla/config functionality. It's bound to not work as well, lacking the 10+ years of testing and bugfixing on the most weird of systems. makexpi.sh is just a wrapper around the scripts there, as is the build system when it comes to zipping up xpis based on jar.mn. You are right that you don't need a compiler, that's not the point. We will need a commandline zip utility and some basic other stuff regardless.

I don't understand your comment regarding a preference for the build system. It requires much more than mozilla/config, but either way, it will also require mozilla/config. Thus, we are bound to get makexpi.sh working if we fulfill the requirements for the build system to work. Using the full build system will then also require having copies of much more than just mozilla/config. Evidently that would be worse.

Comment 5

7 years ago
We use python now, scripts are in venkman's hg repo --> we're done.
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.