Not being familiar with cmake, it sounds like a big thing.
One option might be gmake.
This is an idea, though I would emit some reserve because it could be
considered for many vs users a regression not to have their integrated ide for
building running and tracing fltk in one go.
I'd be willing to take a stab at making a Makefile.WINDOWS
for fltk for the MS compilers if that would be entertaining.
Brave man!
One thing - can you call it Makefile.MS (or similar) please, as I
already have windows makefiles, for non -MS tools...
Cheers,
--
Ian
SELEX
People are quite happy to use the system libraries from within their
IDE's, without building them in that environment, and surely this is
similar?
When using *nix targets, personally I just do everything I need from emacs, but
I must relate that even my unix mentor former colleague (an old
MacArthur, Ian (SELEX GALILEO, UK) wrote:
I'd be willing to take a stab at making a Makefile.WINDOWS
for fltk for the MS compilers if that would be entertaining.
Brave man!
One thing - can you call it Makefile.MS (or similar) please, as I
already have windows makefiles, for non
MacArthur, Ian (SELEX GALILEO, UK) wrote:
I'd be willing to take a stab at making a Makefile.WINDOWS
for fltk for the MS compilers if that would be entertaining.
Brave man!
I actually spent an hour on this, and got just about all the
fltk libs to build under VS .Net
Starting a new thread here for building fltk with gmake.
I find it just too satisfying to build FLTK on Windows using
Microsoft's own compiler *without* the IDE.
New tar file that can be extracted tot he fltk 1.3.x directory as:
http://seriss.com/people/erco/fltk/tmp/vsnet-makefiles-0.20.tar.gz
Fabien Costantini wrote:
The VS Express compiler flags are very different from the other VS
compilers.
Are the VS build files smart enough to recognize compiler differences?
Could you be more specific ?
For now, what I know is that I build the whole demo (with all its deps) in one
Fabien Costantini wrote:
The VS Express compiler flags are very different from the other VS
compilers.
Are the VS build files smart enough to recognize compiler differences?
Could you be more specific ?
For now, what I know is that I build the whole demo (with all its deps) in
I find it just too satisfying to build FLTK on Windows using
Microsoft's own compiler *without* the IDE.
My 2 cents comments on that:
Did you notice how many files are needed to be _added_ to the distrib and in
subdirs of the distrib, we already have unix makefiles, watcom makefiles and
now it
On 01.09.2008, at 01:05, Greg Ercolano wrote:
Fabien Costantini wrote:
On one hand, cmake would avoid this difficulty,
on the other hand, it is not a good thing to force
new users to get cmake for using fltk.
Not being familiar with cmake, it sounds like a big thing.
One
Another subject that I have been torturing my old brain about.
I came up with an XML (or whatever) database containing unified
instructions for building every library and executable in the
archive.
The XML then gets merged with multiple IDE description files
(extracted from an
Fabien Costantini wrote:
I find it just too satisfying to build FLTK on Windows using
Microsoft's own compiler *without* the IDE.
My 2 cents comments on that:
Did you notice how many files are needed to be _added_ to the distrib and in
subdirs of the distrib, we already have unix makefiles,
On 01.09.2008, at 17:51, MacArthur, Ian (SELEX GALILEO, UK) wrote:
As for now, we have unix makefiles, cmakefiles, watcom
makefiles spreading over the whole fltk directory structure,
and more important, we have cxx file lists spread as well. To
be even more clear, I would not mind that much
Hello !
Maybe one crazy idea would be the use of the C preprocessor to
generate the IDE files, so there would be no need to install any
binaries. But it is probably not powerful enough.
That is a great idea. Is it possible to get the
generated text from the preprocessor out again
into a
I was recently playing little bit with cmake and it can generate
portable IDE projects (that is independent on cmake itself) as long as
you set for the generation the directories relative to the build
directory and you do not make checking of external library directories.
That's really
Following the discussion I guess we can have following targets:
1. Standard Makefiles and configure script (as they are) for building on:
- all *nix platforms (including OSX)
- MinGW (using msys to invoke configure script)
- Cygwin
2.1 Cmake generated targets but cmake INDEPENDENT
matthiasm wrote:
But whichever tool we use is only important for the core developers,
since I assume that we would pre-create and distribute all common IDE
files anyways, right?
IMHO not only the _core_ developers, but also everybody who uses svn to access
the newest version, if they would
Torsten Giebl wrote:
That is a great idea. Is it possible to get the
generated text from the preprocessor out again
into a text file ?
Yes, e.g. gcc -E
Stop after the preprocessing stage; do not run the compiler proper. The
output
is in the form of preprocessed source code, which is sent
On 1 Sep 2008, at 18:10, Albrecht Schlosser wrote:
Torsten Giebl wrote:
That is a great idea. Is it possible to get the
generated text from the preprocessor out again
into a text file ?
Yes, e.g. gcc -E
Many systems allow you to simply call cpp directly. Indeed the man
page on this mac
Tim Channon wrote:
Fabien Costantini wrote:
I find it just too satisfying to build FLTK on Windows using
Microsoft's own compiler *without* the IDE.
My 2 cents comments on that:
Did you notice how many files are needed to be _added_ to the distrib and in
subdirs of the distrib, we already
Fabien Costantini wrote:
I find it just too satisfying to build FLTK on Windows using
Microsoft's own compiler *without* the IDE.
My 2 cents comments on that:
Did you notice how many files are needed to be _added_ to the distrib
A lot less files than the number of project files
Fabien Costantini wrote:
Fabien Costantini wrote:
The VS Express compiler flags are very different from the other VS
compilers.
Are the VS build files smart enough to recognize compiler differences?
Could you be more specific ?
I meant all the new manifest flags needed
MacArthur, Ian (SELEX GALILEO, UK [EMAIL PROTECTED] writes:
With that being said,
FLTK is nice, fast, a bit unstable and experimental - but definitely
usable.
You are using fltk-2 IIRC? If you find it a bit unstable and
experimental for your needs, you should maybe give fltk-1 a
matthiasm [EMAIL PROTECTED] writes:
I would go even further and not only copy the label, but also pre-
store wrapping information, graphical elements (@-notation), and the
position of possible shortcut-underscores. It would make the
HelpWidget a hudred times faster and speed up the
On 1 Sep 2008, at 21:23, Brian wrote:
You are using fltk-2 IIRC? If you find it a bit unstable and
experimental for your needs, you should maybe give fltk-1 a spin
too -
it is intended as the stabel and NOT-experimental branch, so that
might be more to your needs?
I'm sorry but i
On 01.09.2008, at 19:06, Albrecht Schlosser wrote:
matthiasm wrote:
But whichever tool we use is only important for the core developers,
since I assume that we would pre-create and distribute all common IDE
files anyways, right?
IMHO not only the _core_ developers, but also everybody who
On 01.09.2008, at 22:27, Brian wrote:
Btw fltk::HelpWidget really needs to have the contents clipboard
copyable.
It does in FLTK1. It should be possible to port that feature to FLTK2
from the FLTK1 code.
http://robowerk.com/
___
I was noticing that (under Windows) when the Visual Studio IDE builds
the release version of fltk, fluid.exe is built as a /SUBSYSTEM:WINDOWS app.
Isn't that a Bad Thing if one tries to use 'fluid -c' from within a Makefile?
I'm probably missing something, but being a /subsystem:windows app,
28 matches
Mail list logo
