[gauging interest] Windows GUI - semi-installer
Hi, After reading the "Customer Friendlier Boost Installation" thread, I've now enough motivation to get into this... I've been planning a boost GUI semi-installer, but hadn't gotten around to it due to lack of time. I call it "semi" in the sense that it wouldn't be the typical "wizard like" installer everyone's used to, but rather a configuring utility for (at least) the IDEs I'm familiar with. Here's what I thought it should do: 1) Register include/lib directories with VCx 2) Don't know how yet, but try the same with BCB (as I think it's on a per-project basis, rather than global settings like VC) 3) Allow building of libraries which require it, with the following options: - Which compiler(s) to use? - Which configuration (debug/threading/static/etc) for each compiler? I believe that detecting which libraries need building would just be a matter of searching for a "build" subdirectory within a given library's directory. Don't know about configurations, though, maybe some simple parsing of the jamfiles would do.. The reason I chose not to do it as an installer, is because I'm far more comfortable with developing GUIs with say, BCB, than I am with the installer programs I've tried. Comments, suggestions, requests are welcome. Pablo Aguilar
"Pablo Aguilar" <pablo.aguilar@gmail.com> writes:
I believe that detecting which libraries need building would just be a matter of searching for a "build" subdirectory within a given library's directory.
Yep.
Don't know about configurations, though, maybe some simple parsing of the jamfiles would do..
Don't try to parse Jamfiles. It will be fragile at best and a disaster at worst. Think of Jamfile contents like C++ source code; you want a real C++ compiler in order to process that and make any sense of it. For Jamfiles you want to do any understanding within Boost.Build.
The reason I chose not to do it as an installer, is because I'm far more comfortable with developing GUIs with say, BCB, than I am with the installer programs I've tried.
Comments, suggestions, requests are welcome.
Making Boost easier to install is crucial. I suggest that parties interested in contributing in some way take the thread to the jamboost list. http://www.boost.org/more/mailing_lists.htm#jamboost If people prefer we could establish a separate list, but I fear there might be a great deal of overlap. -- Dave Abrahams Boost Consulting www.boost-consulting.com
I'm glad to see this thread starting, I definitely think this is a good idea. "David Abrahams" <dave@boost-consulting.com> wrote in message news:uoeay3md4.fsf@boost-consulting.com...
"Pablo Aguilar" <pablo.aguilar@gmail.com> writes:
I believe that detecting which libraries need building would just be a matter of searching for a "build" subdirectory within a given library's directory.
Yep.
Don't know about configurations, though, maybe some simple parsing of the jamfiles would do..
Don't try to parse Jamfiles. It will be fragile at best and a disaster at worst. Think of Jamfile contents like C++ source code; you want a real C++ compiler in order to process that and make any sense of it. For Jamfiles you want to do any understanding within Boost.Build.
As far as JAM interacting with the installer program, why don't you have boost.JAM build the installation program? That way this installer isn't a red-haired bastard stepchild, but just another target in the Boost.build environment. Boost.build is certainly powerful enough! Basically, I'd add a target after "install" that could grab the source and built libraries and feed those files into the installer script, creating a single installer output file (say, "boost_1.32.msi"). Then the boost maintainers could publish just that file on the web.
The reason I chose not to do it as an installer, is because I'm far more comfortable with developing GUIs with say, BCB, than I am with the installer programs I've tried.
Well .. the commercial installers take care of a lot of common issues that occur, adding a layer of reliability and tested code for the common tasks of installing files, editing paths, registry, and displaying a familar user interface. Are you really sure you'd want to stray off the beaten path here?
Comments, suggestions, requests are welcome.
Making Boost easier to install is crucial. I suggest that parties interested in contributing in some way take the thread to the jamboost list.
http://www.boost.org/more/mailing_lists.htm#jamboost
If people prefer we could establish a separate list, but I fear there might be a great deal of overlap.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I'm glad to see this thread starting, I definitely think this is a good idea.
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uoeay3md4.fsf@boost-consulting.com...
"Pablo Aguilar" <pablo.aguilar@gmail.com> writes:
I believe that detecting which libraries need building would just be a matter of searching for a "build" subdirectory within a given
I see from reading the other thread that there seems to be an assumption that running the compiler on the users machine in order to install boost is a only way to install boost, because of the size of the resulting binaries. I'd like suggest a different model. On my machine, the compiled libraries + source (no object files) takes 700MB for all the models for one compiler (VC71 in this case). But, that's uncompressed. Compressed is a different story. When I compress my directory, I get a 90% reduction in size - more like 70MB. But that's still too large. However, a single compile model - ie, single threaded (debug+release) - takes only 4.6MB, which is easily downloadable. And all programming shops I've been to pick a particular compiler, programming model, and then stick with it, so the following idea should work: So, what you'd do it is write a installer stub that displayed a UI 1) queried for compiler model 2) queried for compile model (single threaded, multithreaded, static, dll etc) And then took that information and went off and downloaded the correct library. Seems simple enough to me. Much simpler than trying to recreate the UNIX auto-config behaviour on Windows, because Windows just isn't very robust that way. If you want, I can start to enumerate all of the different ways that the programmers in my shop manage to get it wrong, but it's a dreary list, and I've got the advantage of being able to walk over to their machines and poke around. Usually it's some sort of path issue, but that doesn't make it simple to diagnose. "Robert Mathews" <rmathews@envoyww.com> wrote in message news:d74j5c$7v6$1@sea.gmane.org... library's
directory.
Yep.
Don't know about configurations, though, maybe some simple parsing of the jamfiles would do..
Don't try to parse Jamfiles. It will be fragile at best and a disaster at worst. Think of Jamfile contents like C++ source code; you want a real C++ compiler in order to process that and make any sense of it. For Jamfiles you want to do any understanding within Boost.Build.
As far as JAM interacting with the installer program, why don't you have boost.JAM build the installation program? That way this installer isn't a red-haired bastard stepchild, but just another target in the Boost.build environment. Boost.build is certainly powerful enough!
Basically, I'd add a target after "install" that could grab the source and built libraries and feed those files into the installer script, creating a single installer output file (say, "boost_1.32.msi"). Then the boost maintainers could publish just that file on the web.
The reason I chose not to do it as an installer, is because I'm far more comfortable with developing GUIs with say, BCB, than I am with the installer programs I've tried.
Well .. the commercial installers take care of a lot of common issues that occur, adding a layer of reliability and tested code for the common tasks of installing files, editing paths, registry, and displaying a familar user interface. Are you really sure you'd want to stray off the beaten path here?
Comments, suggestions, requests are welcome.
Making Boost easier to install is crucial. I suggest that parties interested in contributing in some way take the thread to the jamboost list.
http://www.boost.org/more/mailing_lists.htm#jamboost
If people prefer we could establish a separate list, but I fear there might be a great deal of overlap.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Mathews wrote:
I'm glad to see this thread starting, I definitely think this is a good idea.
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uoeay3md4.fsf@boost-consulting.com...
Don't try to parse Jamfiles. It will be fragile at best and a disaster at worst. Think of Jamfile contents like C++ source code; you want a real C++ compiler in order to process that and make any sense of it. For Jamfiles you want to do any understanding within Boost.Build.
As far as JAM interacting with the installer program, why don't you have boost.JAM build the installation program? That way this installer isn't a red-haired bastard stepchild, but just another target in the Boost.build environment. Boost.build is certainly powerful enough!
This is a good idea and something I would provide in my GUI/helper utilities.
Basically, I'd add a target after "install" that could grab the source and built libraries and feed those files into the installer script, creating a single installer output file (say, "boost_1.32.msi"). Then the boost maintainers could publish just that file on the web.
The problem is that the library files generated come to around 520Mb per toolset. Therefore, packaging the *.lib files becomes unrealistic (especially with the countless variations of gcc: is gcc-3.3 version 3.3.0, 3.3.1, ...?) The installer should: * extract the current Boost distribution files; * setup any environment variables; * build bjam; * build the libraries for the selected compilers/versions, noting where to install to, whether Python is supported, etc.; * optionally configure your favorite IDE to find the requested headers and library files.
Well .. the commercial installers take care of a lot of common issues that occur, adding a layer of reliability and tested code for the common tasks of installing files, editing paths, registry, and displaying a familar user interface. Are you really sure you'd want to stray off the beaten path here?
Therefore using a commercial installer would be a good thing. The question is does that installer support executing command lines (to build the Boost files) and can you optionally process that to provide a nice UI/progress for the average user who is going to be daunted by the masses of output generated. The alternative would be to provide Unix and Windows scripts to simplify the build/install process to something like: install-boost c:/boost-1.32 vc-7_1 Reece Haston Dunn Software Engineer, Sophos Web: www.sophos.com Sophos - protecting businesses against viruses and spam
"Reece Dunn" <msclrhd@hotmail.com> wrote in message news:BAY101-F27D3D4829B2FDF38C3BA41A00F0@phx.gbl... [snip]
Basically, I'd add a target after "install" that could grab the source and built libraries and feed those files into the installer script, creating a single installer output file (say, "boost_1.32.msi"). Then the boost maintainers could publish just that file on the web.
The problem is that the library files generated come to around 520Mb per toolset. Therefore, packaging the *.lib files becomes unrealistic (especially with the countless variations of gcc: is gcc-3.3 version 3.3.0, 3.3.1, ...?)
The installer should: * extract the current Boost distribution files; * setup any environment variables; * build bjam; * build the libraries for the selected compilers/versions, noting where to install to, whether Python is supported, etc.; * optionally configure your favorite IDE to find the requested headers and library files.
Agreed for the most part. But wouldn't including a pre-built bjam executable be better? After all, it's not that big a download...
Well .. the commercial installers take care of a lot of common issues that occur, adding a layer of reliability and tested code for the common tasks of installing files, editing paths, registry, and displaying a familar user interface. Are you really sure you'd want to stray off the beaten path here?
Therefore using a commercial installer would be a good thing. The question is does that installer support executing command lines (to build the Boost files) and can you optionally process that to provide a nice UI/progress for the average user who is going to be daunted by the masses of output generated.
You can run just about anything from an installer. My main reason for not using one would that it's not that easy to come back to it and say you want to build another target which you didn't the first time around. And that for Windows Installer packages, the 2nd time around you run a package with the exact same ProductID, you get into maintenance mode (repair/uninstall/reinstall) and well, having no experience with worknig around that, I thought it'd be easier to do a separate tool.
The alternative would be to provide Unix and Windows scripts to simplify the build/install process to something like:
install-boost c:/boost-1.32 vc-7_1
Reece Haston Dunn Software Engineer, Sophos
Web: www.sophos.com Sophos - protecting businesses against viruses and spam
Pablo Aguilar
"Reece Dunn" <msclrhd@hotmail.com> wrote in message news:BAY101-F27D3D4829B2FDF38C3BA41A00F0@phx.gbl...
Robert Mathews wrote:
I'm glad to see this thread starting, I definitely think this is a good idea.
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uoeay3md4.fsf@boost-consulting.com...
Don't try to parse Jamfiles. It will be fragile at best and a disaster at worst. Think of Jamfile contents like C++ source code; you want a real C++ compiler in order to process that and make any sense of it. For Jamfiles you want to do any understanding within Boost.Build.
As far as JAM interacting with the installer program, why don't you have boost.JAM build the installation program? That way this installer isn't a red-haired bastard stepchild, but just another target in the Boost.build environment. Boost.build is certainly powerful enough!
This is a good idea and something I would provide in my GUI/helper utilities.
Basically, I'd add a target after "install" that could grab the source and built libraries and feed those files into the installer script, creating a single installer output file (say, "boost_1.32.msi"). Then the boost maintainers could publish just that file on the web.
The problem is that the library files generated come to around 520Mb per toolset. Therefore, packaging the *.lib files becomes unrealistic (especially with the countless variations of gcc: is gcc-3.3 version 3.3.0, 3.3.1, ...?)
I'm glad to see this thread starting, I definitely think this is a good idea.
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uoeay3md4.fsf@boost-consulting.com...
"Pablo Aguilar" <pablo.aguilar@gmail.com> writes:
I believe that detecting which libraries need building would just be a matter of searching for a "build" subdirectory within a given
Did you see my other post where I addressed that? I'll paste it in here for convenience, sorry if the duplication annoys. What do you think? <<<<<<<pasted post follows>>>>>>> I see from reading the other thread that there seems to be an assumption that running the compiler on the users machine in order to install boost is a only way to install boost, because of the size of the resulting binaries. I'd like suggest a different model. On my machine, the compiled libraries + source (no object files) takes 700MB for all the models for one compiler (VC71 in this case). But, that's uncompressed. Compressed is a different story. When I compress my directory, I get a 90% reduction in size - more like 70MB. But that's still too large. However, a single compile model - ie, single threaded (debug+release) - takes only 4.6MB, which is easily downloadable. And all programming shops I've been to pick a particular compiler, programming model, and then stick with it, so the following idea should work: So, what you'd do it is write a installer stub that displayed a UI 1) queried for compiler model 2) queried for compile model (single threaded, multithreaded, static, dll etc) And then took that information and went off and downloaded the correct library. Seems simple enough to me. Much simpler than trying to recreate the UNIX auto-config behaviour on Windows, because Windows just isn't very robust that way. If you want, I can start to enumerate all of the different ways that the programmers in my shop manage to get it wrong, but it's a dreary list, and I've got the advantage of being able to walk over to their machines and poke around. Usually it's some sort of path issue, but that doesn't make it simple to diagnose. "Robert Mathews" <rmathews@envoyww.com> wrote in message news:d74j5c$7v6$1@sea.gmane.org... library's
directory.
Yep.
Don't know about configurations, though, maybe some simple parsing of the jamfiles would do..
Don't try to parse Jamfiles. It will be fragile at best and a disaster at worst. Think of Jamfile contents like C++ source code; you want a real C++ compiler in order to process that and make any sense of it. For Jamfiles you want to do any understanding within Boost.Build.
As far as JAM interacting with the installer program, why don't you have boost.JAM build the installation program? That way this installer isn't a red-haired bastard stepchild, but just another target in the Boost.build environment. Boost.build is certainly powerful enough!
Basically, I'd add a target after "install" that could grab the source and built libraries and feed those files into the installer script, creating a single installer output file (say, "boost_1.32.msi"). Then the boost maintainers could publish just that file on the web.
The reason I chose not to do it as an installer, is because I'm far more comfortable with developing GUIs with say, BCB, than I am with the installer programs I've tried.
Well .. the commercial installers take care of a lot of common issues that occur, adding a layer of reliability and tested code for the common tasks of installing files, editing paths, registry, and displaying a familar user interface. Are you really sure you'd want to stray off the beaten path here?
Comments, suggestions, requests are welcome.
Making Boost easier to install is crucial. I suggest that parties interested in contributing in some way take the thread to the jamboost list.
http://www.boost.org/more/mailing_lists.htm#jamboost
If people prefer we could establish a separate list, but I fear there might be a great deal of overlap.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
The installer should: * extract the current Boost distribution files; * setup any environment variables; * build bjam; * build the libraries for the selected compilers/versions, noting where
install to, whether Python is supported, etc.; * optionally configure your favorite IDE to find the requested headers and library files.
Well .. the commercial installers take care of a lot of common issues
occur, adding a layer of reliability and tested code for the common tasks of installing files, editing paths, registry, and displaying a familar user interface. Are you really sure you'd want to stray off the beaten path here?
Therefore using a commercial installer would be a good thing. The question is does that installer support executing command lines (to build the Boost files) and can you optionally process that to provide a nice UI/progress for the average user who is going to be daunted by the masses of output generated.
The alternative would be to provide Unix and Windows scripts to simplify
to that the
build/install process to something like:
install-boost c:/boost-1.32 vc-7_1
Reece Haston Dunn Software Engineer, Sophos
Web: www.sophos.com Sophos - protecting businesses against viruses and spam
Yahoo! Groups Links
<*> To visit your group on the web, go to: http://groups.yahoo.com/group/jamboost/
<*> To unsubscribe from this group, send an email to: jamboost-unsubscribe@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Robert Mathews wrote:
"Reece Dunn" <msclrhd@hotmail.com> wrote in message
The problem is that the library files generated come to around 520Mb per toolset. Therefore, packaging the *.lib files becomes unrealistic (especially with the countless variations of gcc: is gcc-3.3 version 3.3.0, 3.3.1, ...?)
Did you see my other post where I addressed that? I'll paste it in here for convenience, sorry if the duplication annoys. What do you think?
I did see it, I just hadn't had chance to reply (the other install-related thread is getting large and I do have a day job :)).
[snip] When I compress my directory, I get a 90% reduction in size - more like 70MB. But that's still too large. However, a single compile model - ie, single threaded (debug+release) - takes only 4.6MB, which is easily downloadable.
And all programming shops I've been to pick a particular compiler, programming model, and then stick with it, so the following idea should work:
But what about your curious semi-knowledgeable user who downloads GCC from the website as binaries, or selects one from cygwin. You can't say Boost supports installing gcc-3.2 and 3.3, but if you have 3.3.1 then you'll have to build the libraries manually.
So, what you'd do it is write a installer stub that displayed a UI 1) queried for compiler model 2) queried for compile model (single threaded, multithreaded, static, dll etc)
And then took that information and went off and downloaded the correct library.
Have you seen my latest post on the other thread. The method I proposed supports both pre-built libraries and a guided build to give the user the choice. It also opens up the setup program to use cases such as: 1. I have a copy of Boost 1.32 on my machine that I am just using headers for (Boost.Build is too complex!). Now I want to use Boost.RegEx on gcc-4.0, but that requires me to use Boost.Build. SOLUTION: run setup.exe; select your local Boost distribution, Boost.RegEx and gcc-4.0; build the libraries and check the results in a friendly summary. 2. I want a standard version of Boost for a supported (w.r.t. pre-build libraries) compiler and don't care about bandwidth as I have a decent connection. SOLUTION: run setup.exe; select next for all options (will download pre-build libraries)! 3. I want to get the latest CVS version of Boost. SOLUTION: run setup.exe; select CVS for download option; use defaults (will build the libraries, not download). 4. I want a standard version of Boost, but have a slow/limited internet connection. SOLUTION: run setup.exe; select defaults except for generating the libraries (select 'build all'). Presto! Everyone is happy :) Reece Haston Dunn Software Engineer, Sophos Web: www.sophos.com Sophos - protecting businesses against viruses and spam
Robert Mathews wrote:
And all programming shops I've been to pick a particular compiler, programming model, and then stick with it, so the following idea should work:
So, what you'd do it is write a installer stub that displayed a UI 1) queried for compiler model 2) queried for compile model (single threaded, multithreaded, static, dll etc)
And then took that information and went off and downloaded the correct library.
What happens when the combination they select is not available as a binary download? We, meaning the Boost developers, can't be expected to build binaries for every possible toolset and combination out there.
Seems simple enough to me. Much simpler than trying to recreate the UNIX auto-config behaviour on Windows, because Windows just isn't very robust that way.
Boost.Config already does that. As pointed out on another post, it's the building of bjam and running it that people need help with. A UI that does that for you would be enough to get over the hurdle. If it also installs extensions to your IDE that make running bjam, or using Jamfiles as projects, directly in the IDE I would think that solves all the getting started issues in the most portable manner. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
[Snip]
Seems simple enough to me. Much simpler than trying to recreate the UNIX auto-config behaviour on Windows, because Windows just isn't very robust that way.
Boost.Config already does that. As pointed out on another post, it's the building of bjam and running it that people need help with. A UI that does that for you would be enough to get over the hurdle. If it also installs extensions to your IDE that make running bjam, or using Jamfiles as projects, directly in the IDE I would think that solves all the getting started issues in the most portable manner.
Thank you Rene! (for saying it clearly) That's exactly the tool I'm proposing!...
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Pablo
"Robert Mathews" <rmathews@envoyww.com> writes:
I'm glad to see this thread starting, I definitely think this is a good idea.
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uoeay3md4.fsf@boost-consulting.com...
"Pablo Aguilar" <pablo.aguilar@gmail.com> writes:
I believe that detecting which libraries need building would just be a matter of searching for a "build" subdirectory within a given library's directory.
Yep.
Don't know about configurations, though, maybe some simple parsing of the jamfiles would do..
Don't try to parse Jamfiles. It will be fragile at best and a disaster at worst. Think of Jamfile contents like C++ source code; you want a real C++ compiler in order to process that and make any sense of it. For Jamfiles you want to do any understanding within Boost.Build.
As far as JAM interacting with the installer program, why don't you have boost.JAM build the installation program?
Well, that's the right idea... but why don't YOU have boost.Jam build the installation program? ;-) Lots of great ideas going around here, but we need people willing to do the work that makes the difference.
That way this installer isn't a red-haired bastard stepchild, but just another target in the Boost.build environment. Boost.build is certainly powerful enough!
Basically, I'd add a target after "install" that could grab the source and built libraries and feed those files into the installer script, creating a single installer output file (say, "boost_1.32.msi"). Then the boost maintainers could publish just that file on the web.
The reason I chose not to do it as an installer, is because I'm far more comfortable with developing GUIs with say, BCB, than I am with the installer programs I've tried.
Well .. the commercial installers take care of a lot of common issues that occur, adding a layer of reliability and tested code for the common tasks of installing files, editing paths, registry, and displaying a familar user interface. Are you really sure you'd want to stray off the beaten path here?
I wouldn't. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Robert Mathews" <rmathews@envoyww.com> wrote in message news:d74j5c$7v6$1@sea.gmane.org...
I'm glad to see this thread starting, I definitely think this is a good idea.
[snip]
As far as JAM interacting with the installer program, why don't you have boost.JAM build the installation program? That way this installer isn't a red-haired bastard stepchild, but just another target in the Boost.build environment. Boost.build is certainly powerful enough!
I'm somewhat confused here, isn't building what we're trying to simplify with this installer?
Basically, I'd add a target after "install" that could grab the source and built libraries and feed those files into the installer script, creating a single installer output file (say, "boost_1.32.msi"). Then the boost maintainers could publish just that file on the web.
While I think that writing .msi files isn't trivial, I think it's worth considering before going any further.. I'll take a look once more at installer programs available.
The reason I chose not to do it as an installer, is because I'm far more comfortable with developing GUIs with say, BCB, than I am with the installer programs I've tried.
Well .. the commercial installers take care of a lot of common issues that occur, adding a layer of reliability and tested code for the common tasks of installing files, editing paths, registry, and displaying a familar user interface. Are you really sure you'd want to stray off the beaten path here?
Well, like I said in my reply to David Abrahams, I didn't quite intend something as an installer, but rather a configuring utility. Very much along the lines of what Reece Dunn posted on the other thread, namely autodetecting available compilers, allowing on-demand building of libraries with varying configurations, and registering/unregistering the include and library paths for each of the target IDEs. I strongly urge you to look at the utility for Win32GUI, as it represents a special-case version of what I had in mind. Do you think an installer (as opposed to a tool like I describe) would be the best way to go? If so, and many others believe it that way, I'll redirect my effort into something like that. [snip] Pablo Aguilar
Pablo Aguilar wrote:
The reason I chose not to do it as an installer, is because I'm far more comfortable with developing GUIs with say, BCB, than I am with the installer programs I've tried.
Well .. the commercial installers take care of a lot of common issues that occur, adding a layer of reliability and tested code for the common tasks of installing files, editing paths, registry, and displaying a familar user interface. Are you really sure you'd want to stray off the beaten path here?
Take a look at Inno Setup: http://www.jrsoftware.org/isinfo.php It's the one I used to create: http://boost-sandbox.sourceforge.net/boost-cvs-setup.exe It's scriptable, and supports custom plugins. The simple script for the above is at: http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost-sandbox/boost-sandbox... http://tinyurl.com/76djb -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera <grafik.list@redshift-software.com> writes:
Pablo Aguilar wrote:
The reason I chose not to do it as an installer, is because I'm far more comfortable with developing GUIs with say, BCB, than I am with the installer programs I've tried.
Well .. the commercial installers take care of a lot of common issues that occur, adding a layer of reliability and tested code for the common tasks of installing files, editing paths, registry, and displaying a familar user interface. Are you really sure you'd want to stray off the beaten path here?
Take a look at Inno Setup:
http://www.jrsoftware.org/isinfo.php
It's the one I used to create:
Is there documentation that describes what that does? Should we be advertising it on the Boost site? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Rene Rivera <grafik.list@redshift-software.com> writes:
Pablo Aguilar wrote:
The reason I chose not to do it as an installer, is because I'm far more comfortable with developing GUIs with say, BCB, than I am with the installer programs I've tried.
Well .. the commercial installers take care of a lot of common issues that occur, adding a layer of reliability and tested code for the common tasks of installing files, editing paths, registry, and displaying a familar user interface. Are you really sure you'd want to stray off the beaten path here?
Take a look at Inno Setup:
http://www.jrsoftware.org/isinfo.php
It's the one I used to create:
Is there documentation that describes what that does?
No, since it's only experimental, hence why it's in the sandbox ;-) But a one line description for what it currently does: "It installs pre-built binaries of the various Boost tools."
Should we be advertising it on the Boost site?
Not unless some one, other than me, is prepared to support it. I made it as I was in the middle of following the disparate instructions on installing/setup to use Boost.Book and figured I would encapsulate the experience in a more repeatable and useful form. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Yesterday, when I decided to start this, I went and downloaded John Torjo's Win32GUI library (www.torjo.com), and noticed that the build utility packaged with it, is very similar to what I originally had in mind. Like I said, I didn't conceive it as an installer, but rather as a tool to build and setup directories, all this while assuming the user would be willing to download and extract boost on his own. "David Abrahams" <dave@boost-consulting.com> wrote in message news:uoeay3md4.fsf@boost-consulting.com...
"Pablo Aguilar" <pablo.aguilar@gmail.com> writes:
[snip]
Don't know about configurations, though, maybe some simple parsing of the jamfiles would do..
Don't try to parse Jamfiles. It will be fragile at best and a disaster at worst. Think of Jamfile contents like C++ source code; you want a real C++ compiler in order to process that and make any sense of it. For Jamfiles you want to do any understanding within Boost.Build.
Ok, I won't argue, as not parsing them would make my life a whole lot easier. I do suggest you take a look at John Torjo's utility though, if I got it correctly, it doesn't parse the .jam files but rather just adds the requested threading/linkage/debug options to the bjam command line.
The reason I chose not to do it as an installer, is because I'm far more comfortable with developing GUIs with say, BCB, than I am with the installer programs I've tried.
Comments, suggestions, requests are welcome.
Making Boost easier to install is crucial. I suggest that parties interested in contributing in some way take the thread to the jamboost list.
http://www.boost.org/more/mailing_lists.htm#jamboost
If people prefer we could establish a separate list, but I fear there might be a great deal of overlap.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Thanks for your comments Pablo Aguilar
"Pablo Aguilar" <pablo.aguilar@gmail.com> writes:
Yesterday, when I decided to start this, I went and downloaded John Torjo's Win32GUI library (www.torjo.com), and noticed that the build utility packaged with it, is very similar to what I originally had in mind.
Like I said, I didn't conceive it as an installer, but rather as a tool to build and setup directories, all this while assuming the user would be willing to download and extract boost on his own.
Sounds helpful.
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uoeay3md4.fsf@boost-consulting.com...
"Pablo Aguilar" <pablo.aguilar@gmail.com> writes:
[snip]
Don't know about configurations, though, maybe some simple parsing of the jamfiles would do..
Don't try to parse Jamfiles. It will be fragile at best and a disaster at worst. Think of Jamfile contents like C++ source code; you want a real C++ compiler in order to process that and make any sense of it. For Jamfiles you want to do any understanding within Boost.Build.
Ok, I won't argue, as not parsing them would make my life a whole lot easier. I do suggest you take a look at John Torjo's utility though, if I got it correctly, it doesn't parse the .jam files but rather just adds the requested threading/linkage/debug options to the bjam command line.
Okay, I can look at it (again; saw it some time ago), but to what end? Is there some way I can help you once I've seen it? -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ubr6xn553.fsf@boost-consulting.com...
"Pablo Aguilar" <pablo.aguilar@gmail.com> writes: [snip]
Ok, I won't argue, as not parsing them would make my life a whole lot easier. I do suggest you take a look at John Torjo's utility though, if I got it correctly, it doesn't parse the .jam files but rather just adds the requested threading/linkage/debug options to the bjam command line.
Okay, I can look at it (again; saw it some time ago), but to what end? Is there some way I can help you once I've seen it?
Yes, thank you... What I'd like to know is if that's a viable option for selecting which targets to build from within a GUI tool. That is, if a jamfile for a given project already has, for example, threading options; will specifying threading at the command line to bjam, create ONLY the what was requested? Rephrasing a little, will the options specified at the CL override or add to those specified in the jamfile? And if it's an override, will that be enough for me to specify build targets without parsing jam files?
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Thanks for your help. Pablo Aguilar
"Pablo Aguilar" <pablo.aguilar@gmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ubr6xn553.fsf@boost-consulting.com...
"Pablo Aguilar" <pablo.aguilar@gmail.com> writes: [snip]
Ok, I won't argue, as not parsing them would make my life a whole lot easier. I do suggest you take a look at John Torjo's utility though, if I got it correctly, it doesn't parse the .jam files but rather just adds the requested threading/linkage/debug options to the bjam command line.
Okay, I can look at it (again; saw it some time ago), but to what end? Is there some way I can help you once I've seen it?
Yes, thank you... What I'd like to know is if that's a viable option for selecting which targets to build from within a GUI tool. That is, if a jamfile for a given project already has, for example, threading options; will specifying threading at the command line to bjam, create ONLY the what was requested?
Rephrasing a little, will the options specified at the CL override or add to those specified in the jamfile? And if it's an override, will that be enough for me to specify build targets without parsing jam files?
Oh, I can answer that without downloading John's tool. There are two kinds of options in Jamfiles: those that specify target requirements (i.e. "needs multithreading" or "needs the FOO preprocessor symbol defined") and those that specify the "default BUILD" (that is, "if not otherwise specified, link to the static runtime library"). The first kind, requirements, can't be overridden at the command-line. The other kind can. HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (5)
-
David Abrahams -
Pablo Aguilar -
Reece Dunn -
Rene Rivera -
Robert Mathews