Small task for Windows programmers

[wysota]

I wonder if it's possible to auto detect the specs like Qt does. The script could then be extended to find it itself.

[marcel]

What do you mean? Qt knows because it's reading the QMAKESPEC env variable.

[wysota]

What do you mean? Qt knows because it's reading the QMAKESPEC env variable.

I mean to be able to auto detect the specs from within the script to set the variable in the first place. If QMAKESPEC is not set, I know qmake tries (and often manages) to detect it. Maybe the script could use it somehow... but it would require qmake to dump the information somewhere, maybe it does...

[jpn]

Perhaps "qmake -query" and/or $QTDIR\.qmake.cache could help somehow? Basically it should be enough to ask for the location of qmake.exe and everything else could be then figured out..

[wysota]

Under Linux in the specs directory there is a soft link called "default" that points to the default specs. I don't know if there is anything similar on Windows, but that could be a way to detect the specs.

If we can't make it all happen from within a script, maybe a small statically compiled app using QWizard would be an option as well...

[marcel]

Under Linux in the specs directory there is a soft link called "default" that points to the default specs. I don't know if there is anything similar on Windows, but that could be a way to detect the specs.

If we can't make it all happen from within a script, maybe a small statically compiled app using QWizard would be an option as well...

I thought of this too.
I think I'm gonna make a wizard that also let's you fully configure, compile and install Qt Open Source.
I don't know if I'm gonna write it with Qt or when it's gonna be ready, but I hope sometime soon.

[wysota]

What do you think about letting the user choose the make spec/compiler in the script interface?

Yes, that's an option too. If it can't detect the platform itself, it can fall back to asking the user.

I think I'm gonna make a wizard that also let's you fully configure, compile and install Qt Open Source.

I thought of this too, but didn't have time to start working on it and also there is a problem with switches changes between different versions. If you wanted help, I'd be willing to provide it.

[marcel]

Ok, just had a quick look at the qmake sources.
It expects the user to provide the make spec either as a qmake option( -spec or -platform ) or in the QMAKESPEC environment variable. If it cannot find it this way, it takes the default, which is located in QTDIR/mkspecs/default. The problem is that in the opensource version this folder does not exist. In the version precompiled for mingw it exists and it is the same as win32-g++ and for the commercial versions is set according to the msvc version of the distribution.
If it cannot find it in the default directory error it displays an error message:

if(cmd & ReadConf) {             // parse mkspec
            QString qmakespec = fixEnvVariables(Option::mkfile::qmakespec);
            QStringList mkspec_roots = qmake_mkspec_paths();
            debug_msg(2, "Looking for mkspec %s in (%s)", qmakespec.toLatin1().constData(),
                      mkspec_roots.join("::").toLatin1().constData());
            if(qmakespec.isEmpty()) {
                for(QStringList::ConstIterator it = mkspec_roots.begin(); it != mkspec_roots.end(); ++it) {
                    QString mkspec = (*it) + QDir::separator() + "default";
                    QFileInfo default_info(mkspec);
                    if(default_info.exists() && default_info.isDir()) {
                        qmakespec = mkspec;
                        break;
                    }
                }
                if(qmakespec.isEmpty()) {
                    fprintf(stderr, "QMAKESPEC has not been set, so configuration cannot be deduced.\n");
                    return false;
                }
                Option::mkfile::qmakespec = qmakespec;
            }

if(cmd & ReadConf) {             // parse mkspec
            QString qmakespec = fixEnvVariables(Option::mkfile::qmakespec);
            QStringList mkspec_roots = qmake_mkspec_paths();
            debug_msg(2, "Looking for mkspec %s in (%s)", qmakespec.toLatin1().constData(),
                      mkspec_roots.join("::").toLatin1().constData());
            if(qmakespec.isEmpty()) {
                for(QStringList::ConstIterator it = mkspec_roots.begin(); it != mkspec_roots.end(); ++it) {
                    QString mkspec = (*it) + QDir::separator() + "default";
                    QFileInfo default_info(mkspec);
                    if(default_info.exists() && default_info.isDir()) {
                        qmakespec = mkspec;
                        break;
                    }
                }
                if(qmakespec.isEmpty()) {
                    fprintf(stderr, "QMAKESPEC has not been set, so configuration cannot be deduced.\n");
                    return false;
                }
                Option::mkfile::qmakespec = qmakespec;
            }

To copy to clipboard, switch view to plain text mode 

So I think it is ok and enough to provide a dropdown or a list with all the makespecs available on windows and let the user choose from them

...and also there is a problem with switches changes between different versions

No problem whatsoever. VS also has the option to switch between different Qt installations, but it does it internally.
It is just a matter of setting the environment variables to the desired installation.

[wysota]

No problem whatsoever. VS also has the option to switch between different Qt installations, but it does it internally.
It is just a matter of setting the environment variables to the desired installation.

No, I meant something else. Configuration options change between versions. To avoid creating a new installer for each new version, the software should be able to auto detect those switches and be able to handle them without rebuilding the installer.

[marcel]

Yes, I see now. The problem with this is that the options are stored inside configure, which is an executable(vs a script on linux).

I don't think there is a problem in creating a new version of the installer. Qt releases are not that often and I think it is normal to update the installer to handle the new qt version.

Maybe the options together with their descriptions should be stored in an external file, which should be updated with every qt release, while keeping the options for the older releases. This way the installer doesn't have to be rebuilt.

[wysota]

You can always run configure -help and inspect the options, so an external file is not that important. The problem is you have to think about handling those options afterwards The simplest solution is to just... ignore new switches or give a list of options to enable/modify them at the end of the configuration process and I think it's a good solution for a start.

[marcel]

You can always run configure -help and inspect the options, so an external file is not that important. The problem is you have to think about handling those options afterwards The simplest solution is to just... ignore new switches or give a list of options to enable/modify them at the end of the configuration process and I think it's a good solution for a start.

I'll think about it. I will choose the solution which seems most fit on a long term.
I think I will start this project this week, but I don't know when it's gonna be ready. Hope it won't take more than two weeks.

[marcel]

Perhaps "qmake -query" and/or $QTDIR\.qmake.cache could help somehow? Basically it should be enough to ask for the location of qmake.exe and everything else could be then figured out..

I don't think we can use that... qmake -query QMAKE_MKSPECS only gives you the path where the make specs are located.

but it would require qmake to dump the information somewhere, maybe it does...

Maybe have the script output a test program and then call qmake and parse its output?
I don't really trust this method. What if qmake can't tell the correct make spec?

What do you think about letting the user choose the make spec/compiler in the script interface?