We need a mechanism (via a #define?) using which the Mozilla/GRE milestone can be accessed from within embedding applications. If we used a #define to pick up the Mozilla/GRE milestone then we do not have to manually update embedding clients each time Mozilla changes it's milestone. For ex, we have the milestone (1.2b as of this writing) hardcoded into the two files below: http://lxr.mozilla.org/mozilla/source/embedding/tests/mfcembed/winEmbedFileLocProvider.cpp#207 http://lxr.mozilla.org/mozilla/source/embedding/qa/testembed/winEmbedFileLocProvider.cpp#200 leaf : i've currently assigned this bug to you. Please reassign if you're not the correct owner...thanks
can this use milestone.txt?
Target Milestone: --- → mozilla1.3alpha
sure. we just need to get a generic way to search/replace, guessing with a makefile target and a perl script. Then the template file will have __MOZILLA_MAJOR_MILESTONE__.__MOZILLA_MINOR_MILESTONE__ or something, which will be parsed to a new file before the compile. on my todo list...
Assignee: leaf → asasaki
depends on patches for http://bugscape.netscape.com/show_bug.cgi?id=17934 getting r/sr/a.
Created attachment 106040 [details] [diff] [review] gets rid of hardcoding in win32 mfcembed files this works on win32. however, i need to make sure it doesn't break the other platforms' builds, especially mac.
unfortunately, one of the first things i noticed on macos9 is that winEmbedFileLocProvider.cpp.tmpl is too long of a filename. we can rename this, or we can wait until we stop supporting os9. does this even get built on the mac?
cool. renamed those two files and nothing broke on os9.
Comment on attachment 106040 [details] [diff] [review] gets rid of hardcoding in win32 mfcembed files I don't like the idea of making those source files templates just to add 2 defines. Why not just add the defines to configure.in or at the very least mfcembed/Makefile.in ?
Attachment #106040 - Flags: review?(cls) → review-
cls: just for cpp files? this is how i did the bugscape bug http://bugscape.netscape.com/show_bug.cgi?id=17934 it's quite possible we'll end up with 10-20 defines, depending on when os9 gets phased out, especially with the new stupid marketing version that has to go in commercial. but i can do cpp files one way and all other files the other if necessary.
None of the patches that I reviewed for that bugscape bug had any .cpp files referenced in them. We did discuss the problem of picking up generated .cpp files from the objdir which should have clued me in. Unless you get leaf to copy the .cpp file to the .tmpl file in the cvs repo, you're going to lose the cvs history of that file. We generally try to avoid file renames for that reason. Besides, it's c++...as opposed to xul or whatever uses the .dtd files. If you want to avoid using configure.in, you can easily generate a new header file from a new template and #include that header in the existing .cpp files. There's no need to convert each c++ source file into a template when the language allows for #includes & #defines.
Created attachment 108810 [details] [diff] [review] with -D option sent through makefile is this right? it builds, but I'm not sure if the MOZILLA_VERSION is actually replaced correctly during the build.
Attachment #106040 - Attachment is obsolete: true
Comment on attachment 108810 [details] [diff] [review] with -D option sent through makefile Not quite. MOZILLA_VERSION is available from config/autoconf.mk. There's no need to generate it in each Makefile that uses it. Since the value of -DMOZILLA_VERSION isn't guaranteed to be a number, you'll want to quote the value as it's passed into CXXFLAGS: -DMOZILLA_VERSION=\"$(MOZILLA_VERSION)\" . Should we just set this define in configure.in so that it shows up with the rest of the system-wide defines? For the define to be substituted in C/C++, it needs to be unquoted. - strcpy(szKey, "Software\\Mozilla\\GRE\\1.3a"); + strcpy(szKey, "Software\\Mozilla\\GRE\\" MOZILLA_VERSION);
Attachment #108810 - Flags: review-
we might want to add it to configure.in, but for a lot of the build/release files, at least, we need a lot more specific splits like MOZILLA_MAJOR_VERSION, MOZILLA_MINOR_VERSION, mini, micro, and then sometimes you need a leading zero etc. etc. probably depends on how many cpp files actually reference the full version for it to be worth it? working on the new patch.
Created attachment 108833 [details] [diff] [review] with proper quoting etc.
Attachment #108810 - Attachment is obsolete: true
Attachment #108833 - Flags: review+
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.