Get rid of windows solution files

[Tom Fogal]

Maintaining both the visual studio + qmake build files is a pain. The two systems are always out of sync, and doing something like adding a new source file is a chore. It makes running our continuous integration system difficult, because there needs to be more "windows path" versus "POSIX path", which creates a verbose build specification.

Recent qmake's seem to actually create something that works on Windows, or at least almost works. Unfortunately these don't seem capable of building a solution that can build both win32 and win64 from a single session. This doesn't seem like a huge loss; we can still test all configurations against every commit, if we want.

[Jens Krüger (jens-sci)]

Hi Tom,

the trouble with the qmake files is the (as far as I know) limited feature set, there are a few settings that we NEED for the projects and a few thing that I really LIKE to have. The NEED things are pre and post build scripts, is there anything like that in qmake? As far as the the linke things go there are "per file compiler warning settings" for instance, in VS studio I can selectively disable warning without having to put pragmas into the file, another really nice thing is the ability to combine multiple solutions into a single project. Can we configure any of these settings into qmake project files?

Cheers
  Jens

Am 14.06.2010 um 21:18 schrieb Tom Fogal:

> Public bug reported:
>
> Maintaining both the visual studio + qmake build files is a pain. The
> two systems are always out of sync, and doing something like adding a
> new source file is a chore. It makes running our continuous integration
> system difficult, because there needs to be more "windows path" versus
> "POSIX path", which creates a verbose build specification.
>
> Recent qmake's seem to actually create something that works on Windows,
> or at least almost works. Unfortunately these don't seem capable of
> building a solution that can build both win32 and win64 from a single
> session. This doesn't seem like a huge loss; we can still test all
> configurations against every commit, if we want.
>
> ** Affects: imagevis3d
> Importance: Low
> Assignee: ImageVis3D Developers (iv3d-developers)
> Status: Confirmed
>
> ** Changed in: imagevis3d
> Importance: Undecided => Low
>
> ** Changed in: imagevis3d
> Assignee: (unassigned) => ImageVis3D Developers (iv3d-developers)
>
> ** Changed in: imagevis3d
> Status: New => Confirmed
>
> --
> Get rid of windows solution files
> https://bugs.launchpad.net/bugs/594301
> You received this bug notification because you are a member of
> ImageVis3D Developers, which is a bug assignee.
>
> Status in ImageVis3D, an out-of-core desktop volume renderer: Confirmed
>
> Bug description:
> Maintaining both the visual studio + qmake build files is a pain. The two systems are always out of sync, and doing something like adding a new source file is a chore. It makes running our continuous integration system difficult, because there needs to be more "windows path" versus "POSIX path", which creates a verbose build specification.
>
> Recent qmake's seem to actually create something that works on Windows, or at least almost works. Unfortunately these don't seem capable of building a solution that can build both win32 and win64 from a single session. This doesn't seem like a huge loss; we can still test all configurations against every commit, if we want.
>
>

[Tom Fogal (tfogal)]

Jens Krüger <email address hidden> writes:
> the trouble with the qmake files is the (as far as I know) limited
> feature set, there are a few settings that we NEED for the projects
> and a few thing that I really LIKE to have. The NEED things are pre
> and post build scripts, is there anything like that in qmake?

Probably. I'm not quite sure what you mean by pre and post build
scripts... but like a makefile, you can define arbitrary targets, and I
imagine dependencies between targets.

I define a step in IO/test/test.pro, for example, which builds the
implementation from some header files using cxxtestgen.py. This is set
up to happen before the main build (since building that implementation
file *is* the main build ;)

> As far as the the linke things go there are "per file compiler
> warning settings" for instance, in VS studio I can selectively
> disable warning without having to put pragmas into the file,

I'd really prefer the pragmas.

Putting that kind of information in the build system instead of the
source sucks, because you can't move the source somewhere else. I
recently tried to copy UVF into VisIt, for example, and it was a
nightmare in part because we do things like this.

Source annotations encourage that kind of lateral movement. Further,
version control systems work better with source lines (since they
aren't autogenerated), so it is easier to uncover *why* a particular
suppression was introduced.

> another really nice thing is the ability to combine multiple
> solutions into a single project. Can we configure any of these
> settings into qmake project files?

You mean multiple vcproj's in a single .sln? We already do this in
ImageVis; one just needs to use SUBDIRS. You can also put multiple
targets into a single qmake file. Beyond that, I don't follow.

-tom

> Am 14.06.2010 um 21:18 schrieb Tom Fogal:
>
> > Public bug reported:
> >
> > Maintaining both the visual studio + qmake build files is a pain. The
> > two systems are always out of sync, and doing something like adding a
> > new source file is a chore. It makes running our continuous integration
> > system difficult, because there needs to be more "windows path" versus
> > "POSIX path", which creates a verbose build specification.
> >
> > Recent qmake's seem to actually create something that works on Windows,
> > or at least almost works. Unfortunately these don't seem capable of
> > building a solution that can build both win32 and win64 from a single
> > session. This doesn't seem like a huge loss; we can still test all
> > configurations against every commit, if we want.
> >
> > ** Affects: imagevis3d
> > Importance: Low
> > Assignee: ImageVis3D Developers (iv3d-developers)
> > Status: Confirmed
> >
> > ** Changed in: imagevis3d
> > Importance: Undecided => Low
> >
> > ** Changed in: imagevis3d
> > Assignee: (unassigned) => ImageVis3D Developers (iv3d-developers)
> >
> > ** Changed in: imagevis3d
> > Status: New => Confirmed
> >
> > --
> > Get rid of windows solution files
> > https://bugs.launchpad.net/bugs/594301
> > You received this bug notification because you are a member of
> > ImageVis3D Developers, which is a...