Feature Freeze for 2.1.0 release

[graemeg]

Hi,

I’ve merged the IDE work along with a few other updates. If you have a moment, any last-minute testing would be greatly appreciated before I roll out the 2.1.0 release this Sunday.

For a sneak peek at the changelogs, follow this link.

And for the adventurous ones 😅, here is the IDE merge commit:

    For the IDE to actually be useful in developing and debugging
    you need to use FPC 3.3.1 with the OPDF code merged in. See
    my Github repos for pre-built binaries for linux x86_64
    platform.
    
    You'll also need to clone the opdebugger repo, build and
    install the 'opdf-lib', 'pdr-adapters' and 'pdr-core'
    libraries via PasBuild.
    
    Lastly, uncomment the opdf module dependencies in the
    ide/project.xml file so that the IDE can be compiled with
    full debugging enabled using FPC 3.3.1
    
    Hopefully FPC team will get there act in gear and start
    making releases again. So this process will become
    much simpler. A man can dream! ;-)

• FPC 3.3.1 + OPDF (linux) release binaries: https://github.com/graemeg/fpc-opdf-releases
• OPDF Debugger repo: https://github.com/graemeg/opdebugger

Regards,
Graeme

[rchastain2]

Just compiled and tested successfully Eschecs and DocView.

While writing the following script (my DocView updater), I wondered if it wouldn't a good idea to add docview.inf to FPGUI/docview/target.

## up-docview.sh
printf "This is $BASH_SOURCE\n"

## My desktop file for DocView
SHORTCUT=~/Desktop/docview.desktop

## DocView help file
INF=docview.inf

if [ ! -v FPGUI ]; then
printf "[ERROR] Variable not defined: FPGUI\n"
exit 0
elif [ ! -d $FPGUI ]; then
printf "[ERROR] Directory not found: %s\n" $FPGUI
exit 0
elif [ ! -f $SHORTCUT ]; then
printf "[ERROR] File not found: %s\n" $SHORTCUT
exit 0
elif [ ! -f $INF ]; then
printf "[ERROR] File not found: %s\n" $INF
exit 0
fi

printf "[INFO] fpGUI directory: %s\n" $FPGUI

pushd $FPGUI
printf "[INFO] Pull\n"
git pull
printf "[INFO] Build\n"
pasbuild clean
pasbuild compile -p unix
popd

DATE=$(date +"%y%m%d")
DIR="docview-$DATE"

printf "[INFO] Copy %s/docview to %s\n" $FPGUI $DIR
cp -rf $FPGUI/docview $DIR

printf "[INFO] Update %s\n" $SHORTCUT
sed -i -E "s/apps\/docview-[0-9]+/apps\/$DIR/g" $SHORTCUT

printf "[INFO] Copy %s\n" $INF
cp $INF $DIR/target

printf "[INFO] Done\n"

[graemeg]

Thank you for taking the time to test the latest code. Much appreciated.

I wondered if it wouldn't a good idea to add docview.inf to FPGUI/docview/target.

Yes, that makes perfect sense and is planned. The goal is a full end-to-end build pipeline going from source to full binaries, all packaged up for release. It's not there yet—or at least not in the way I want it to be.

PasBuild has supported plugins since the v1.7.0 release; a plugin could be a simple bash script, compiled .pas code, etc. This allows a plugin to register a new goal, such as docs-compile, similar to the built-in compile and test-compile goals. That plugin could then trigger a wipfc call and output a binary .inf to the target directory of DocView. That's already possible today, but it's a bit "clunky."

My ideal solution would be to take advantage of the PasBuild layout convention for the source directory structure. For example:

docview
     +- src
           +- main
                +- pascal
                |    +- <all docview .pas code here>
                +- ipf
                     +- <docview's help source .ipf>

This would allow two different language directories, using different compilers, with the generated binaries landing in the same docview/target directory—all triggered with a single pasbuild compile -m fpgui-docview -p unix command. I'll have a think on this, maybe a plugin is the way to go here, I just need to restructure the directory layout as shown above. 🤔

[graemeg]

My other (one of many) 😅 goal, is to implement wipfc in object pascal, so it supports all fpGUI target platforms with a native ipf compiler.

[rchastain2]

Very interesting. So I could use, for example, pandoc to generate the documentation of an application? Or imagemagick to generate an image? So much possibilities...

If I may give my opinion on the second point, I think it would be good to keep the link with the Open Watcom project. Why remake what already exists?

[graemeg]

Very interesting. So I could use, for example, pandoc to generate the documentation of an application? Or imagemagick to generate an image? So much possibilities...

Exactly! 😃 And I gave it a lot of thought on how to support plugins, and avoid the FPC .ppu/.o binary compatibility mess. Where all projects need to use exactly the same FPC compiler version, otherwise they don't play together.

My solution (actually borrowed the idea from the Git project itself) doesn't care what language is used to implement the plugins, and the plugin talks to PasBuild itself to find out everything it needs to know about the project. And PasBuild talks to the plugin, to know where in the pipeline it needs to register the plugin goal. All done via stdout results.

If you want to find out more about PasBuild plugins. Have a look here: https://github.com/graemeg/PasBuild/tree/master/extras/plugins/hello-world
I created the same "hello world" plugin using a simple bash script, and the second example uses a compiled .pas file. Both have the exact same functionality.

It's really very simple to create plugins, and it shouldn't require any changes in PasBuild code itself.

If I may give my opinion on the second point, I think it would be good to keep the link with the Open Watcom project. Why remake what already exists?

True. It would be a awful lot of effort, and then simply produce the same result. And that's exactly why I've been putting in off for years now. And rather include the wipfc binaries with fpGUI instead. :)

[graemeg]

@rchastain2 I've implemented a pasbuild plugin for compiling .ipf files. I'm sure it could do with a few more improvements, but it works for now. You can build it via: pasbuild compile pasbuild-docs-compile

Then copy the tools/docs-compile/target/pasbuild-docs-compile binary to <fpgui>/plugins or to the global ~/.pasbuild/plugins.

It will try and use the <fpgui>/tools/wipfc/wipfc binary (or the Windows wipfc.exe)

As it's not related or dependent on FPC compiled code in fpGUI, it will not trigger the normal compilation of source code. It's a independent command. Ran as: pasbuild docs-compile -m fpgui-docview

[andrewd207]

For a sneak peek at the changelogs, follow this link.

That's a huge list!

There are (maybe were) some oddities with the way copy paste/selection works. Like pasting text is left selected. I don't know if that got changed. I hadn't updated in a bit so I'll look.

[graemeg]

That's a huge list!

Yeah, quite a bit of work went into 2.1.0 :)

I recall the edit cursor ending up on the left of a selection after a paste, but might have fixed it at some point. I couldn't reproduce it now. But if you can - please let me know the steps. Thank you.

[graemeg]

Ha, just saw your patch. Taking a look now.